Requirements vs. Feasibility
The two major differences between the requirements phase and the feasibility phase are:
By the requirements phase, a decision has been made to continue with development; the feasibility phase lacks that assurance.
The requirements phase is concerned with detailed
specifications; the feasibility phase is appropriately
Who Conducts the Software Requirements Analysis?
Software systems analysts develop the software requirements with participation from any of the following: hardware specialists, communications specialists, lead programmers, database specialists, and documentation specialists. Additional key participants should be the customer and users of the system. Their subject-matter expertise is critical to the success of the future system. Lack of either group's involvement at this stage often results in substantial system rework.
The Software Feasibility Report (from the definition of the project) is a primary input into the analysis and development of the software requirements. In fact, many of the aspects of the software system that were analyzed during concept definition will be revisited during requirements. The analysts refine the high-level system objectives into a prioritized, detailed, and quantifiable set of conditions. Note that the system requirements developed and documented during this period become the basis for the development of the overall software system design, the software system test plan, and the software user-acceptance test plan. It is critical, therefore, that requirements be complete, explicit, and contain measurable acceptance criteria.
Software Requirements Document
The software requirements document should be developed to describe both what the system does and what it does not do. Too often, it is tacitly assumed that anything left out of the document will not be added to the system. (Quirk, W. J., ed. 1985. Verification and Validation of Real-Time Software. New York: Springer-Verlag. 23.) Functional requirements can be documented in text or graphics of varying degrees of formality and automation suiting the complexity of the system.
Key Aspects of the Software Requirements Specification
The final prioritized set of requirements for a software system is often developed through a series of negotiations between customers and software systems analysts with special consideration given to user needs, the technical feasibility of the desired system, system controls, system scheduling, and ultimately, the system cost. Various requirements may be stated in terms of alternatives that are purposely left open-ended at this point in the development process. Later, during software system design, all alternatives will be resolved. Ten key activities that systems analysts must address during requirements analysis are:
describe the current environment
define the scope of the new system
develop input and output requirements
define the system's functions
catalog user requirements
list performance requirements
itemize operational requirements
identify maintenance requirements
specify external controls
develop exception handling requirements
Describe the Current Environment
A new system often replaces an existing system or automates tasks currently performed manually. In either case a detailed study of the current environment should be completed. This study should give special attention to user activities and to the flow of data in the environment.
Define the Scope of the New System
An important activity in requirements analysis is to define clearly the scope and limits of the new system. Kirk urges analysts to "stretch the limits of the system to their natural boundaries." (Kirk, Frank. 1973. Total System Development for Information Systems. New York: John Wiley and Sons. 85.)
The requirements document should detail the scope of the new system and identify related activities that will not be part of the new system. This approach highlights these items and clarifies the system's limitations.
Define the System's Functions
A system's functions are those processes that occur to transform the identified inputs into the required outputs. The system is designed and implemented based on these functions.
System functions should be described logically rather than physically; by what should be done rather than how. (Davis, Alan. 1988. "A Comparison of Techniques for the Specification of External System Behavior." Communications ACM, September.) This is due to the volatility of the requirements. New aspects of the system are discovered frequently, impelling frequent changes to the requirements. It is better to tie functionality to implementation in the design step when volatility has decreased.
Develop Input and Output Requirements
Each input and each output for the new system must be identified and described, including input source(s), and output destination(s). References to external interfaces must also detail their requirements. Feedback - where input is dependent on output - must be considered. (Wymore, A. Wayne. 1976. Systems Engineering Methodology for Interdisciplinary Teams. New York: John Wiley and Sons. 111-165.) Although many input and output details are specified during requirements analysis, methods for implementing them are not, since that is a function of system design. The following list of input and output attributes specifies aspects to explore:
Catalog User Requirements
Identifying the users of the new system and the associated requirements is a large part of the requirements effort. Necessary details include: who the users are, how many users, the users' skill levels, the training required for the new system, the stability of the user population, the type and amount of documentation needed, and geographical considerations. Special consideration may be required for external users, as opposed to internal users.
It is vital that users perceive the system as meeting their needs. This perception is separate from whether the system actually does meet their needs. Too often, users do not base appraisals either on how well-designed the system is or on how well-managed the development effort is, but rather on the adequacy of their interface to the system. This interface includes not only user-machine communications, but also ease of using the documents. (Page- Jones, Meilir. 1988. The Practical Guide to Structured Systems Design. 2nd ed. Englewood Cliffs, NJ: Yourdon Press. 286.)
List Performance Requirements
All system requirements must be measurable and must have associated acceptance criteria, especially when detailing the system performance expectations. Inadequate or unacceptable system performance is a primary ingredient of user dissatisfaction.
Performance requirements in particular should be bounded rather than open- ended and so prevent over- or under-design. Here is an example of an open- ended requirement:
"Response time for task X must not exceed 5 seconds."
Given this requirement, several questions remain unanswered:
What may the user expect as the normal or average response time? Is it 5 seconds or something less than 5 seconds?
If average response time is less than 5 seconds, how much less?
Should the system be designed for an average
response time of 1 second with a response time not to exceed 5 seconds under
To remove the ambiguity, a better statement of the response time requirement might be:
"Response time for task X under average load conditions for the system should be in the 2- to 3-second range."
"During peak load periods, the response time must not exceed 5 seconds."
Optimizing the design for the 2- to 3-second response range can be very different from trying to design for the lowest possible response time. With the revised requirement, a designer has a specific design target and users and system testers have specific acceptance criteria. Note: Average load and peak load must be clearly defined in the requirements for this to be an effective response time requirement.
Any system, particularly real-time systems, may have many performance requirements. The success of the system hinges on the specificity of the requirements. Several aspects of a system for which performance attributes should be examined and described include:
Itemize Operational Requirements
The requirements for a system's operations cover a broad range. In most development efforts, the hardware and software components are not chosen until the design phase. Specifications may cite a particular processor size (that is, mainframe, minicomputer, or microcomputer) or require compatibility with a particular system. The physical location of the new system may also pose constraints, and these must be documented. Additional requirements may include resource parameters: use of memory, disk storage, file size, conversion requirements (for replacement systems), data redundancy, processor redundancy, off-site storage, backup capability, and recovery capability.
Identify Maintenance Requirements
The requirements for a system's maintenance cover every aspect of the system. The basis for good itemized maintenance requirements is a well thought out maintenance concept that describes how and who will do the maintenance. The maintenance concept should cover both software and hardware maintenance. It should also separate maintenance tasks performed by the user from maintenance tasks performed by trained maintenance personnel. The maintenance requirements should cover items such as level and types of tests, backup capability and schemes, and routine and emergency maintenance procedures. The overall maintenance concept and requirements may significantly impact the system architecture and the actual software.
Many systems being developed today must adhere to external controls placed
on the system. These may include business or government regulations,
environmental controls, safety controls, or even political and social
controls. All such requirements must be clearly specified during system
Develop Exception Handling Requirements
The exception handling requirements of a system involve a definition of the
actions to be taken when undesired events or conditions occur. In a critical
system involving life-threatening situations, exception handling receives top
priority. In such a case, requirements for damage control or confinement may
need to be developed. In less critical systems, requirements are concerned
with system or user error messages, or with exception reports. Analysts often
create categories of exceptions and define error handling in terms of the
severity of the error category.
Software Requirements Review
The final requirements specification documents for a software system must
be formally reviewed and accepted in a Software Requirements Review. Those
involved in the review include: customers, users, software analysts, hardware
designers, software designers, hardware testers, software testers, and
Software requirements specifications, although accepted, are not valid
until it is determined that the resulting software system can be built for a
reasonable cost. This requires the development of one or more software
designs, which is generally the next step in software development.
After the Software Requirements Review, the Software Requirements Document
should be baselined and placed under change control. Additionally, system
resource estimates and schedules for the software should be updated to reflect
modifications resulting from the review.
Most large, complex projects can expect changes to the system's
requirements as software development progresses. Proposed changes to the
requirements must be closely monitored, however, since they have the potential
for large rippling effects as the software system development matures.
Accepted revisions to the requirements must be reflected in the requirements
specifications documents and they must be quickly and clearly communicated to
the entire development team so that resource adjustments, if necessary, can be
managed and coordinated.