Software Requirements Engineering: Process, Tools & Best Practices
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.
- Introduction to Requirements Engineering: Importance of requirements engineering in software development
- The Software Requirements Specification: Qualities, structure, and role of the SRS document
- Languages for Requirements Specification: Automated Tools: Overview of automated tools for real-time systems
- PSL/PSA and RSL/REVS: Automated specification languages and their applications
- Structured Analysis and Design Technique (SDAT): Graphical modeling approach for complex systems
- Effects of Poor Requirements Analysis: Real-world consequences of inadequate requirements specification
- Conclusion: Summary of requirements engineering's role in project success
✍️ How to write this paper — guide, tools & examples ▾
What makes this paper effective
- The paper moves logically from broad concepts (the SDLC and requirements engineering) to specific technical tools (PSL/PSA, RSL/REVS, SDAT), giving readers a structured, layered understanding of the field.
- A concrete real-world failure — the American Airlines AMRIS system — grounds the abstract discussion of requirements quality in tangible consequences, including a specific dollar loss figure.
- The paper maintains a consistent focus on the "what" vs. "how" distinction in software development, clearly separating the requirements phase from the design and coding phases.
Key academic technique demonstrated
The paper uses authoritative citation to reinforce technical claims — drawing on Fairley's Software Engineering Concepts for definitional content and the Standish Group report for empirical evidence of project failure. This blending of textbook authority with industry research data is a hallmark of undergraduate technology writing.
Structure breakdown
The paper opens with a broad introduction establishing the importance of requirements engineering, then provides a detailed treatment of the Software Requirements Specification and SDLC workflow. Three subsections survey automated specification tools (PSL/PSA, RSL/REVS, and SDAT). A case-study section on real-world failure provides analytical weight before a concise conclusion restates the central argument. The structure follows a classic problem–context–tools–consequences–recommendation arc.
Introduction to Requirements Engineering
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
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.
Languages for Requirements Specification: Automated Tools
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).
Conclusion
It is imperative that developers and analysts gain a thorough understanding of system needs and prepare a comprehensive software requirements specification. Properly employed requirements engineering would go a long way toward improving software quality and reducing the costs incurred in production by a significant margin. Software requirements fall within the domain of the systems analyst, whose responsibility it is to communicate user needs clearly to the programmers. With the ever-increasing complexity of software technology, arriving at a sound software requirements specification is indispensable to the success of any project.
Bibliography
Fairley, Richard. Software Engineering Concepts. Tata McGraw-Hill, 2000, p. 89.
The Standish Group. "The Standish Group Report." Accessed 16 February 2003.
Thomas, Bill. "Meeting the Challenges of Requirements Engineering." Accessed 16 February 2003.
Always verify citation format against your institution’s current style guide requirements.