Notes On Requirements Analysis

Requirements analysis is part of a larger process -- see our software development "mandala"

Don't forget: this process will take different forms depending on the nature of the job you're doing.

Definition of requirements: a description of the needs that must be met. Anything that drives design; Model of software needs. In general, requirements are what, not how!

Why requirements??

• Save money: the earlier a mistake or problem is encountered, the easier and cheaper it is to fix.
• Preserve agreements: people leave -- and what exists only in their minds goes with them!
• Prevent misunderstanding: I thought you said... Didn't you mean? I assumed...
• Keep things manageable: Prevent feature creep. Stabilize expectations
• Plan resource usage effectively

Gotcha's! include "gold plating,", feature creep, misunderstanding!

gathering requirements

be sure you're asking the right people

Process

High level description (Understand their situation)

Modeling (User scenarios; who needs to do what and why?)

Documenting the requirements; prevent ambiguity and risk.

Agreement with customer. Sign off.

What makes for a good requirement? complete, correct, feasible, necessary, prioritized, unambiguous, verifiable

What makes for a good set of requirements? complete, consistent, modifiable, and traceable

Some Examples of Deficient requirements (from Software Requirements, Karl Wiegers, Microsoft Press)

1. The product shall provide status messages at regular intervals not less than every 60 seconds. Would one message per nano second be OK?
2. The product shall switch between displaying and hiding nonprinting characters instantaneously. Without warning? Any reason for this?
3. The parser shall produce an HTML markup error report that allows quick resolution of errors when used by HTML novices. I guess HTML experts are out of luck!
4. Charge numbers should be validated against the master corporate charge number list, if possible. Programmer didn't feel like doing it -- is it then impossible? When might it be possible?
5. The product shall not offer search and replace options that could have disastrous effects. Why on earth not? But seriously, what type of "disastrous " effects are we talking about?

What types of requirements exist?

• User interface
• Functionality
• Outside interfaces (monitoring, database, etc. )
• Constraints related to hardware, software, coding practices, etc.
• business rules (e.g. Who can perform what function? What departments are involved?)

Vision and Scope

Table of Contents

Use Case Template

Software Requirements Specification

Table of Contents

Revision History

1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Project Scope
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3. External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4. System Features
4.1 System Feature 1
4.2 System Feature 2 (and so on)
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
6. Other Requirements

Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: To Be Determined List