CS486 - Senior Capstone Design

Guidelines for Requirements Capture

Overview

To develop a thorough understanding of what the customer wants and what the major difficulties will be. Remember:

1. the focus is on what is to be accomplished, not on how it is to be accomplished.
2. your aim at this point is to describe the requirements in domain terms, not geeky terminology. This means there should be no talk of modules, languages, objects, and so on (unless the client expressely specifies it) --- all of this stuff is an "implementation concern", to be considered later when you turn your attention to how you will satisfy the requirements. In short, your client -- whatever his or her level of technical expertise -- will have to be able to understand and sign off on your characterization of the requirements in order for the project to move forward. Proceed accordingly.

Some issues to address/consider as you gather requirements:

1. Functional Requirements - Requirements that impact product functionality.

1.1 What is the product supposed to do? (detailed)
1.2 What is the expected usage environment? (detailed)
1.3 What information/materials are given to the product?
1.4 What internal data must the product contain?
1.5 How is the product expected to behave at each stage of use?
1.6 How long is the product expected to work?
1.7 How continuously will the product be in use?
1.8 Describe the operator's involvement with the product.
1.9 Physical and environmental constraints on product usage.
1.10 Distinguish between customer "need" and "wants".
1.11 How does this product compare with existing products?

2. Performance and Non-Functional Requirements - Requirements that do not impact product functionality.

2.1 Process Requirements - requirements placed on the development process.

2.1.1 Standards Requirements - Restrictions placed on the development standards (e.g., military standards, OSHA, EPA, etc.)
2.1.2 Delivery Requirements - Restrictions placed on product delivery (e.g., deadlines, installation, training, etc.)
2.1.3 Implementation Requirements - Restrictions placed on the problem solution (e.g., language requirements, design methodology, open vs. closed architecture, etc.)

2.2 Product Requirements - Requirements placed on the completed product.

2.2.1 Usability Requirements - Restrictions caused by expected user base (e.g., nontechnical users, high turn-over rate, etc.)
2.2.2 Performance Requirements - Restrictions caused by customer performance expectations (e.g., energy consumption, throughput capacity, runtime speed,, etc.)
2.2.3 Space Requirements - Physical or memory limitations.
2.2.4 Reliability Requirements - Restrictions on the availability and usability of the product (e.g., product must function at maximum efficiency 98% of the time.)
2.2.5 Maintenance Requirements - Restrictions caused by expected maintenance (e.g., expected modifications, etc.)

2.3 External Requirements - Requirements that are neither process or product centered.

2.3.1 Legislative Requirements - Legal limitations or internal standards that constrain development (e.g., EPA regulations, certification issues, etc.)
2.3.2 Cost Constraints - Any financial restrictions imposed by the customer.
2.3.3 Other Constraints - Environmental (computers, languages, …), interfaces.
2.3.4 Inter-operability Requirements - Restrictions caused by the need for the finished product to interface with other systems (e.g., product must automatically update the existing company database with no changes to the current database schema, etc.).