Software Engineering: A Methodical Approach (2014)
PART B. Software Investigation and Analysis
Chapter 4. The Requirements Specification
This chapter introduces the second major deliverable in a software engineering project — the requirements specification. It provides an overview of the deliverable, and prepares you for details that will be covered in the next four chapters. The chapter proceeds under the following subheadings:
· Introduction
· Contents of the Requirements Specification
· Documenting the Requirements
· Requirements Validation
· How to Proceed
· Presenting the Requirements Specification
· Summary and Concluding Remarks
4.1 Introduction
The software requirements specification (RS) is the second major deliverable in a software engineering project. It is a document that signals the end of the investigation and analysis phase, and the beginning of the design phase. Its contents will serve as a blueprint during design and development.
Note Remember, we are not assuming that life cycle model being employed is necessarily the waterfall model, which is irreversible. Rather, please assume that any of the reversible life cycle models is also applicable.
The requirements specification must be accurate as well as comprehensive, as it affects the rest of the system’s life in a significant way. Any flaw in the requirements specification will put pressure on the subsequent phases (particularly design and development) to attempt to address it. If the problem is not identified and addressed by the end of system development, then it must be addressed during the maintenance phase — a particularly undesirable situation. In some instances, this might be too late to attempt saving a reputation of a software product.
The requirements specification serves as a very effective method of system documentation, long after system development.
Note Many texts on software engineering recommend one comprehensive requirements specification document that involves detailed design issues. From experience, this is not a good idea, especially if the software being developed is very large and complex. The approach recommended by this course is to have a requirements specification, which provides comprehensive and accurate coverage of the system, but avoids fine design intricacies (such as characteristics of data elements, operation specifications, use of technical language for business rules, system names for objects, etc). This blueprint is then used as input to the design phase, where all intricacies are treated in a separate design specification.
As you go through this chapter, bear in mind that you will need to gain mastery of a number of techniques in order to develop a requirements specification for a project. The intent here is to provide you with the big picture, so you will have an appreciation of where you are heading.Chapters 5 through 8 will then work you through the required details.
4.2 Contents of the Requirements Specification
The requirements specification is comprised of a number of important ingredients. These will be briefly described in this section.
Acknowledgments: This is recognition of individuals and/or organizations or offices that significantly contributed to the achievement of the deliverable. Typically, it is written last but appears as the first item in the requirements specification.
Problem Synopsis: This involves the problem statement, proposed system solution, and system objectives: having been drawn from the ISR (see chapter 3), these would be refined by now. The problem synopsis should also involve a brief review of feasibility findings (the details you can include as appendix).
System Overview: This should provide a broad perspective of the software system. An information topology chart (ITC) and/or an object flow diagram (OFD) are/is particularly useful here. These techniques will be discussed in chapter 6.
System Components: Since your prime objective is to provide clarity about the requirements of the software being engineered, it is a good habit to provide a list of the subsystems, modules, entities (object types) and operations.
Detailed Requirements: This involves specification of the software requirements in a concise, unambiguous manner. This involves the use of narrative, flow-charts, diagrams and other techniques where applicable. These techniques will be discussed in chapters 6 and 7. Depending on the size and complexity of the project, the requirements may be specified for the system as a whole (if the system is small), for subsystems comprising the system (in the case of medium sized to large systems), or for modules comprising subsystems (if the subsystems are large). An approach that has been successfully employed by the author is to include the following in the detailed requirements:
· Storage Requirements: The information entities (object types) and how they are comprised.
· Operational Requirements: The operations to be defined on the information entities (object types).
· Business Rules: The rules of operation. These include derivation rules, relationship integrity rules, data integrity rules, control conditions, and trigger rules. Rules are more thoroughly discussed chapter 7.
Interface Specification: This involves the guidelines relating to how various subsystems and/or modules will be interconnected. Depending on the project, this may or may not be critical at this point. In many cases, it can be deferred until the design phase (in fact, it will be elucidated later in the course).
System Constraints: This involves the operating constraints of the system. Like the interface specification, this requirement may be trivial and self-evident, or critical to the success of the software. An example of triviality would be in the case of an information system (for instance, and inventory management system) for an organization. An example of situation where system constraints would be critical is a real time system (for instance managing atmospheric pressure in an air craft, or water pressure for a water power station).
Revised Project Schedule: Here, you provide a refined project schedule, which involves a PERT diagram or Gantt chart, or some other equivalent means. This will be discussed in chapter 8.
System Security Requirements: Depending on the intended purpose and use of the software product, system security will be an issue to be considered. In specifying the security requirements, the following must be made clear:
· What users will have access to the system
· What system resources various users can access and how
· What restrictions will apply to various users
Concluding Remarks: Usually, there are some concluding remarks about the requirements specification. These are placed here.
Appendices: The appendices typically include supporting information that are relevant to the software requirements, but for various reasons might have been omitted from the body of the document. Examples of possible information for the appendices are
· Investigation and analysis team
· Proposed design and development team(s)
· Photocopy of approval(s) from end-user and management
· Photocopies of source documents used in investigation and analysis
· Detailed feasibility report
4.3 Documenting the Requirements
Documenting the requirements will depend to a large extent on the intended readership and the software tools available. If the intended readership is strictly technical people such as software engineers, then unnecessary details can be avoided, technical jargons are allowed and formal methods may be used (more on this later). If the intended readership includes non-technical individuals (lay persons), then it is advisable to develop an easy to read document.
The requirements specification may be developed with inexpensive applications such as MS Office, Corel Suite, etc. If a CASE tool is available, it should be used since this will enhance the system development process. In fact, in many cases, the diagrams used in the CASE tool are executable — code is generated from them — so that the distinction of requirements specification from design and design from development are absent (hence the term modeling). However, in many instances, thorough documentation is achieved by employing a mix of software development tools and desktop applications.
Preparation of the requirements specifications is perfected only as the software engineer practices on the job. Whether a CASE tool or desktop publisher is used, you will need to have mastery of fundamental software engineering principles, if the end product is to be credible.
4.4 Requirements Validation
Once the requirements have been specified, they must be validated. This is crucial, since it is these requirements that will be used as the frame of reference for the next deliverable - the design specification. If the requirement specification is lacking in content or accuracy, this will have adverse repercussions on the design and final product. There are two approaches to requirements validation: manual and automatic.
Manual Techniques: In manual review, a resource team is used to cheek the following:
· Each specification must be traceable to a requirement definition
· Each requirement definition is traceable to a specification
· All required specifications are in place
· All system objectives are met
The techniques available for this (these will be discussed in the next chapter) are
· Interviews
· Questionnaires
· Document review
· Sampling and Experimenting
· Observation
· Prototyping
· Brainstorming
· Manual cross-referencing
· Mathematical proofs
Automatic Techniques: In automatic techniques, an attempt is made to automate the validation process. This involves technique such as cross-referencing, prototyping, automated simulations models, and, mathematical proofs. Automatic validation is not always feasible, but when applied, is quite helpful.
Discuss: Which life cycle model would most favor automatic validation techniques?
4.5 How to Proceed
How you proceed to develop the RS is a matter of personal preference. Some people like a top-down approach; others prefer a bottom-up approach. Traditional systems employed functional-oriented methods; contemporary systems tend to favor object-oriented methods. In this course, you will be exposed to both approaches, even though there is a bias to the object-oriented approach.
It preparing the RS, it is recommended that you be methodical and incremental, revisiting formerly addressed issues whenever you need to. Figure 4-1 describes a recommended approach that you will find useful in various scenarios. You will notice a few newly introduced terms; these will be clarified in the upcoming chapters.
Figure 4-1. How to Prepare the Requirements Specification
4.6 Presentation of the Requirements Specification
It is often required that the requirements specification be presented to a group of experts and possible end users for scrutiny. Should you have the responsibility to do this, below are some guidelines:
· Have a summarized version for the purpose of presentation.
· Make the presentation interesting by using a balanced mix of the various resources at your disposal.
· Have photocopies for the critical audience.
· Make allocation and be prepared for questions.
· Here are some positive tips:
· Be thoroughly prepared
· Project loudly
· Have a positive eye contact
· Make visuals large enough for audience to see
· Speak in your natural language, tone style
· Be confident and calm
Your presentation must be aesthetically attractive and compelling. As such, you should make use of an appropriate presentation software product (examples include Microsoft PowerPoint, Microsoft Publisher, Corel Draw, Page Maker, etc.).
4.7 Summary and Concluding Remarks
Let us summarize what we have covered in this chapter:
· The RS is the second major deliverable of a software engineering project. It must be accurate and comprehensive.
· The RS typically consists of the following components: acknowledgments, problem synopsis, system overview, detailed requirements, interface specification, system constraints, revised project schedule, security requirements, conclusion, and appendices.
· The requirements may be documented using a CASE tool or a desktop processing application.
· Requirements validation ensures that the software requirements are accurate. The process may be manual or automatic.
· In preparing the RS, it is recommended that you be methodical and incremental in your approach.
· You may be required to make a formal presentation of the RS. Preparation is of paramount importance.
Appendix 9 provides excerpts from the RS of the inventory management system that was mentioned in the previous chapter. Take some time to review it and gain useful insights. But to get to that point where you are able to prepare such a document on your own, you need to learn some more fundamentals, commencing with information gathering techniques. This will be discussed in the next chapter.
4.8 Review Questions
1. Explain the importance of the requirements specification.
2. Identify six important ingredients of the requirements specification. For each, briefly explain what it is and why it is important.
3. How important is requirements validation? Describe two approaches to requirements validation.
4. Outline clearly, how you would proceed to develop a requirements specification for a software engineering project.
4.9 References and/or Recommended Readings
[Kendall, 1995] Kendall, Kenneth E. and Julia E. Kendall. Systems Analysis and Design 3rd ed. Upper Saddle River, NJ: Prentice Hall, 1995. See chapters 13 and 14.
[Lee, 2002] Lee, Richard C. and William M. Tepfenhart. Practical Object-Oriented Development With UML and Java. Upper Saddle River, NJ: Prentice Hall, 2002.
[Martin, 1993] Martin, James and James Odell. Principles of Object Oriented Analysis and Design. Eaglewood Cliffs, NJ: Pretence Hall, 1993.
[Peters, 2000] Peters, James F. and Witold Pedrycz. Software Engineering: An Engineering Approach. New York, NY: John Wiley & Sons, 2000. See chapter 3.
[Pfleeger, 2006] Pfleeger, Shari Lawrence. Software Engineering Theory and Practice 3rd ed. Upper Saddle River, New Jersey: Prentice Hall, 2006. Chapter 4.
[Schach, 2005] Schach, Stephen R. Object-Oriented and Classical Software Engineering 6th ed. Boston, MA: McGraw-Hill, 2005. See chapter 10.
[Sommerville, 2006] Sommerville, Ian. Software Engineering 8th ed. Reading, MA: Addison-Wesley, 2006. See chapter 6.