Information Technology Reference
In-Depth Information
Output processes send information across the application boundary. The
recipients of information would be an entity (an individual, a machine or another
computer application). The output could be normal data in the form of a report
either on paper or computer screen or to another application, or it could be control
data in the form of trigger to another application. The giving/receiving application
can be on another computer or another machine.
Associative processes are those processes that aid and assist the input and
output processes in information processing. Consider a login process; it is neither
an input nor an output. Similarly a file upload is a process; and so is an integrity
checking process and so is the POD (Power On Diagnostics) process. These are all
examples of associative processes.
Requirements elicitation/gathering is mainly enumerating all the processes that
form a part of a software application and obtaining details about these processes so
that downstream activities can be executed without further reference to the client
or with minimal reference to the client.
Now each process has these attributes:
1. Inputs—each process receives certain inputs. While input processes receive
inputs from external sources, output processes and associative processes receive
inputs from the internal sources.
2. Outputs—Each process delivers some outputs. While output processes deliver
to external recipients, input processes and associative processes deliver to
internal recipients.
3. Process—each process carries out some transformation of inputs and converts
them to outputs. Each process consists of some related steps with a start and an
end event. The process includes verification of the inputs for their complete-
ness, appropriateness and freedom from errors.
4. Triggers—each process needs a trigger that initiates the process into execution.
The trigger could be an event initiated by an individual or another application
or could even be by the application itself.
When we enumerate all the processes and define all the above four aspects for
each of the processes comprising the software application, we have a complete
requirements specification document.
2.7 Evolution of Requirements
Requirements start out as a single idea and over a period of time, evolve into a full
set which can then be further processed into a software product. The phases in the
evolution of requirements are discussed in this section. Please note that it is not
mandatory that every organization uses these phases; some of the phases may be
dropped or some other phases may be used; or they may use different set of phases
altogether.
 
Search WWH ::




Custom Search