Examples of cases where systems failed because of lack of communicaitons between different groups working on the project:
Requirements elicitaiton and analysis involves first collecting as many potential requirements as possible, then refining them to form a complete, concise and consistent set of high-quality functional and non-functional requirements, and then analyzing them to start forming a preliminary model of the system to be developed. Functional requirements are often modeled wih the aid of use-cases and scenarios, while the analysis step starts to identify some of the candidate objects / classes that will be needed in the system.
4.3.1 - Functional Requirements
Functional requirement describe the things that the system must DO. They can often be derived from "stories" about how the system will be used, which may be in the form of scenarios, use-cases, or just a simple description of operations such as that shown here:
4.3.2 - Nonfunctional Requirements
Nonfunctional requirements are other properties or characteristics that the system must have, other than its basic functionality. Because non-functional requirements are generally more difficult to identify, checklists of some kind are often used to make sure that developers consider all possibilities and do not leave out anything important. For example:
- FURPS+ :
- Functional
- Usability
- Reliability
- Performance
- Supportability
- Implementation requirements
- Interface requirements
- Operations requirements
- Packaging requirements
- Legal requirements
4.3.3 - Completeness, Consistency, Clarity, and Correctness
- The first step towards specifying requirements is to gather as many potential requirements as possible, regardless of quality considerations.
- However before the final set of requirements can be accepted, both individual requirements and the overall set of requirements must pass through a "quality gateway" that only accepts high-quality requirements, and rejects others, ( or sends them back for further review and refinement. ) For example, some of the qualities that might be examined include:
4.3.4 - Realism, Verifiability, and Traceability
- Realistic - Is the requirement reasonably attainable?
- Verifiable / Measurable / Testable - If you cannot devise a test that will determine whether or not a requirement has been met, then there is no point in including the requirement. For this reason, requirements must also be specific. Example: Bad: "The system must be easy to use". Better: "The system must be easy enough to use that new users can successfully create and print a document within 10 minutes of first starting the system."
- Traceable - Requirements should be traceable back to the source from which they originated, and traceable forward to the classes and code that implements them and to the tests that test for them. They may also include references to external standards or other documents.
4.3.5 - Greenfield Engineering, Reengineering, and Interface Engineering
- Greenfield Engineering refers to projects that start with a fresh empty "green" field.
- Reengineering projects involve modifying an existing system to make it better somehow
- Interface Engineering projects do not change the underlying functionality of an existing system, but improve its interface, either between the system and humans or between the system and some other ( possibly third-party ) system(s).
4.4.1 - Identifying Actors
4.4.2 - Identifying Scenarios
- Four types of scenarios:
- As-is scenarios describe the current situation.
- Visionary scenarios describe a future system.
- Evaluation scenarios describe user tasks to be used to evaluate the system.
- Training scenarios are used for tutorials and other training aids.
4.4.3 - Identifying Use Cases
4.4.4 - Refining Use Cases
The following aspects of use cases are detailed during refinement:
- The elements that are manipulated by the system are detailed.
- The low-level sequence of interactions between the actor and the system are specified.
- Access rights ( to initiate scenarios ) are specified
- Missing exceptions are identified and their handling specified.
- Common functionality among use cases are factored out.
4.4.5 - Identifying Relationships among Actors and Use Cases
Communication relationships between actors and use cases
Extend relationships between use cases
Include relationships between use cases
Extend versus include relationships
- Use include relationships to factor out commonly occurring normal activities that are common to multiple use-cases. Included use-cases are often capable of standing alone as use-cases, and are usually invoked from other use-cases at predictable points. Example: Printing.
- Use extend relationships to document unusual, exceptional, error, and rarely occurring use-cases. Extend use-cases generally cannot stand alone, and in general could be invoked from any point in a number of use cases. Example: Power failure.
4.4.6 - Identifying Initial Analysis Objects
4.4.7 - Identifying Nonfunctional Requirements
4.5.1 - Negotiating Specifications with Clients: Joint Application Design
4.5.2 - Maintaining Traceability
4.5.3 - Documenting Requirements Elicitation
4.6.1 - Initial Problem Statement
4.6.2 - Identifying Actors and Scenarios
4.6.3 - Identifying Use Cases
4.6.4 - Refining Use Cases and Identifying Relationships4.6.5 - Identifying Nonfunctional Requirements
4.6.5 - Identifying Nonfunctional Requirements
4.6.6 Lessons Learned
The following material is excerpted from "Mastering the Requirements Process", 2nd edition, by Robertson and Robertson. It is a required textbook when I teach CS 442, Software Engineering II.
See also the Software Engineering Projcet Report Template developed for CS 440 at UIC, part II
