This paper examines the role of requirements engineering in the software development life cycle (SDLC), explaining how thorough requirements analysis underpins successful software projects. It covers the purpose and qualities of a Software Requirements Specification (SRS), the stages from feasibility study through functional specification, and several automated specification tools including PSL/PSA, RSL/REVS, and the Structured Analysis and Design Technique (SDAT). The paper also presents a real-world case study — the failed AMRIS reservation system — to illustrate the costly consequences of poor requirements analysis, and concludes by emphasizing the systems analyst's responsibility in bridging user needs and technical implementation.
Computer software technology has improved significantly over the past decade, leading to more efficient and comprehensive information systems. With the growth in the number of computing systems comes a corresponding increase in their complexity. Today, software requirements analysis has become an indispensable part of software development. Over the years there has been continued emphasis on the importance of properly planned project evaluation, requirements specification, and system design.
The system development life cycle incorporates the complete analysis, design, and maintenance of any software project, wherein each phase is meticulously planned and built upon the previous one. The software requirements engineering process is part of the analysis phase of the software development life cycle. Once requirements are thoroughly assessed, a comprehensive software requirements specification is drafted. This is a technical specification of what the software is expected to do. Unlike the software design phase — which deals with the actual technicalities of implementing the software — the requirements phase simply specifies what is expected of the final product. A properly developed specification is a prerequisite for the success of any software project. One of the main causes of software project failure is poor attention paid to requirements engineering. Poorly drafted requirements specifications may lead to developing software that fails to satisfy the needs of the user.
The software requirements specification is a comprehensive document that presents all the different aspects involved in software development. This includes the product overview, data flow, functional requirements, performance requirements, methods for handling exceptions, and provisions for future modification. It is desirable that the requirements specification be correct, complete, consistent, clear, functional, verifiable, traceable, and easily modifiable. If requirements are badly stated or incomplete, developers may end up building software that technically satisfies the written requirements but still falls far short of user expectations (Fairley, 93).
There are many models used in the software development life cycle (SDLC). All of these models invariably generate a requirements specification document as the foundation of development. The very first phase in the SDLC is developing the feasibility report. The scope of the proposed project is precisely identified and deficiencies in the existing system are determined. Once the preliminary investigation confirms that the project is technically, economically, and operationally feasible, the next step is requirements analysis.
After understanding the system, the next phase is to detail the operations to be performed by the system in the context of both external and internal objects. The inputs and outputs to the system, as well as the data to be retained, are identified. Several control features that users can employ to monitor the system are also specified. This detailed analysis is documented in a report known as the Functional Specification.
Once the analysis is complete, developers have a clear understanding of what is to be done. They then proceed with system design based on the Functional Specification report. Programmers use the design specification to develop the software, at which stage the actual coding takes place. Documentation is produced simultaneously, as it is indispensable for both testing and future maintenance. The software is then tested with test data to check for logic errors before actual implementation. Elicitation, solution determination, specification, and maintenance are the core aspects of requirements engineering.
For real-time software systems such as defense applications, requirements specification is of the utmost importance. The latest automated tools must be used in conjunction with manual processes to arrive at a proper requirements specification.
Furthermore, a given functional specification can often be satisfied by any one of several different software structures. In selecting a particular structure, quality considerations must be weighed carefully. The software architecture chosen is especially critical in real-time defense applications. As Rick Kazman of SEI Interactive explains: "Each requirement suggests certain architectural structures and rules other ones out. I will choose one set of architectural structures over another because I know that it's a good architecture for being able to predict and control end-to-end latency or throughput, or that it's a good architecture for high availability" (Thomas).
"Automated specification languages and their applications"
"Graphical modeling approach for complex systems"
"Real-world consequences of inadequate requirements specification"
The Standish Group. "The Standish Group Report." Accessed 16 February 2003.
Thomas, Bill. "Meeting the Challenges of Requirements Engineering." Accessed 16 February 2003.
You’re 57% through this paper. Sign up to read the remaining 3 sections.
Sign Up Now — Instant Access Already a member? Log inAlways verify citation format against your institution’s current style guide requirements.