- Requirements Documents
- Business Requirements - Vision and Scope
- User Requirements - Use Case Model
- Software Requirements Specification
- Functional Requirements
- Nonfunctional Requirements
- The Data Dictionary
Requirements engineering takes a fair amount of experience to become proficient at. Even then, much of the process involves work with business-specific processes and jargon. Thus, you need a good understanding of the business to do a good job gathering and analyzing requirements for a particular business.
Recognizing that, it should be obvious that requirements engineering is a collaborative effort. Software developers often find themselves invited to meetings where requirements for a project are to be discussed. Their role is expected to be technical advisor, stating 'that can be done' or 'that would take forever', etc., and the document resulting from that meeting is a bulleted list of features - maybe prioritized and probably with due dates.
For small informal projects that will take one or two days, a simple bulleted list of features may be fine. Other projects should ramp up the formality and size of the requirements with the formality and size of the project. The key reasons are:
- to make certain everyone knows what is being built - what business process is being addressed, what features will be available, what features will not be available, and that there is consensus
- to avoid implementing features incorrectly
- to avoid forgetting to implement a feature that is needed
- to produce a document that can be referenced during testing
- to produce a document that can be referenced when creating user documentation
- to more accurately estimate the amount of time it will take to complete the project
Three classes of requirements are the products of requirements analysis and design:
- business requirements - the vision and scope of the product
- user requirements - the use cases
- software requirements - sometimes referred to as functional requirements, it should contain nonfunctional requirements as well. Describes the outward appearance and behavior of the software in detail. Note that the internal behavior is specified in a technical specification, which is written using the requirements specification as a guide.
Likewise, the requirements document names are:
- Vision and Scope document
- Use cases
- Software requirements specification - contains both functional and nonfunctional requirements.
Document naming conventions are loose - other documents you may have heard about and their roles in the requirements process:
- functional requirements - also known as functional specification, the same as requirements specification.
- system requirements - incorporated into functional requirements, system requirements describe the environment in which the software will operate.
- technical specification - the software design document, describes the internal behavior and design of the software. Covered in Design Specs
A good approach to requirements documentation is to start with templates.
Business Requirements - Vision and Scope
Projects grow out of some need, say in a business environment. Some opportunity is defined - a product or a way to make the business run more efficiently - and a solution is envisioned. In its simplest form the envisioned solution is the objective of the project, the vision of the solution.
At this point the business objective is known, and a few definitions about the project should be written down in a vision and scope document:
- Describe the background of the business need.
- Describe the opportunity presented by recognizing a solution.
- Describe the risks incurred to the business if the project proceeds.
- Indicate what the success factors are.
The business objective helps define limits for project requirements - the features and functions that will be present, i.e. the scope of the requirements. Any requirement that does not apply to the business objectives should be removed. Add descriptions of project scope to the vision and scope document:
- Describe major functions and features that address the business problem.
- Describe what features should be present in initial and subsequent releases.
- Prioritize the features
User Requirements - Use Case Model
Software Requirements Specification
Software requirements specifications (SRS) contain both funtional and nonfunctional requirements of the system.
Functional requirements are documented in a functional specification. The functional specification describes the system by specifying both input and output conditions. The system is described in detail, including the program's purpose, constraints and flexibility, and features by project phase. Functional specifications should include:
- High-level flow chart(s) of the system.
- Low-level flow chart(s) describing flow through the program.
- Every message box, the text of the message, and code path for each choice should be described.
- Wire-frame mockups of each form, screen, or dialog
- Screen shots of finished forms, screens, and dialogs from a prototype.
These are characteristics the system must exhibit, usually considered quality attributes because they do not relate to any specific function of the system
The Data Dictionary
Not directly part of a requirement, the data dictionary defines business specific terms and technical terms. Particularly, terms that have different common and technical meanings. This should be separate from the SRS, and not duplicated in other documents to prevent the situation where terms are defined differently in the documents.
Wiegers, Karl E., 1999, Software Requirements: Microsoft Press, 350 pages. ISBN: 0-7356-0631-5
Kruchten, Philippe, 1999, The Rational Unified Process: An Introduction: Addison-Wesley, 255 pages. ISBN: 0-201-60459-0