Requirements

New Version for Fall 2014

References:

1. Bernd Bruegge and Allen H. Dutoit, "Object-Oriented Software Engineering", Third Edition, Chapter 4.
2. Suzanne Robertson and James Robertson, "Mastering the Requirements Process", Second Edition.
3. Volere Requirements Resources web site, http://www.volere.co.uk/index.htm.

Key Concepts

• Requirements are clear unambiguous statements regarding functionality the final product must have, other properties it must have besides functionality, and related issues such as the procedures used to produce it.
  • Functional requirements describe the functionality the product must have, in terms of things that the system must DO.
  • Non-functional requirements describe other properties the system must have, such as capacity or performance specifications. Some non-functional requirements may specify the process by which the system is developed, such as particular CASE tools or security clearances for developers.
• 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).

An Overview of the Requirements Development Process

From the point of view of the requirements development team, e.g. Robertson & Robertson:

The Role of Requirements Specification in the Software Development Process

From the point of view of the software developer, e.g. Bruegge and DuToit:

or put another way, in this excerpt from the SE Process Flow Diagram:

Determining Functional Requirements Through Use-Cases

• A use-case is a clearly defined step-by-step description of how the system responds in a particular example of using the system.
• By examining the actions that the system takes during a use-case the necessary functionality of the system can be determined, in the form of requirements.
• It is sometimes easier to develop these first as scenarios, which are less formal and less rigidly formatted than use-cases.
  
  
• Identifying Actors

• 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.

  

• Identifying Use Cases

• 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

• Identifying Relationships among Actors and Use Cases on Use-Case Diagrams

Communication relationships between actors and use cases

Includes relationships between use cases

Extends relationships between use cases

Includes versus extends 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.

• Functional requirements should really be expressed in the form of "The system must . . .".
  • When doing so, be careful to describe what the system must do, not what the user must do.
• Functional requirements may also sometimes be expressed in the form of simple description of operations such as that shown here:

Determining Non-Functional Requirements

• The most common approach for the determination of non-functional requirements is through the use of checklists.
• One of the most common checklists is FURPS+ :
  • Functional
  • Usability
  • Reliability
  • Performance
  • Supportability
  • Implementation requirements
  • Interface requirements
  • Operations requirements
  • Packaging requirements
  • Legal requirements

Example Developing Requirements using Use-Cases:

• The problem
• The solution

Other Techniques for Determining Requirements

The following table is from Robertson and Robertson

• Elephant projects are big and heavy, with a lot of inertia. They require a lot of people, a lot of time, and have to be developed slowly and carefully. Once they are completed, they are likely to be used for years and years.
• Rabbit projects are small, quick, and respond quickly to change. They are typically developed by a few people in a short time frame, and may not be kept very long once they are complete.
• Horse projects fall between elephants and rabbits.They are sure, steady, and typically take a small group of developers a little while to develop. Once they are built they are kept for a significant time period
  
  
• Business events are any sort of external stimulus that the business ( or the system ) must respond to, e.g. initiating actions in use-cases. Robertson and Robertson advocate partitioning requirements according to the business use-case from which they were derived, just for organizational purposes.

• Robertson and Robertson also advocate the use of snow cards for keeping track of requirements:

• The data from these snow cards can be easily placed in a spreadsheet. Here are some related documents from the Volere web site:
  • A blank printable snow card
  • A blank spreadsheet, with headers
  • A sample spreadsheet, filled in for a Library Loan example
  • A partially completed requirements document, describing the same Library Loan Example
• Please see http://www.volere.co.uk/index.htm for more information on these documents and the Atlantic Systems Guild

Maintaining High Quality Requirements

• 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:
  • 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.
  • Correctness - Are there any errors in the requirement? Where numbers are involved, are all the values correct?
  • Clarity - Is the requirement clearly understood by everyone involved? Are there any ambiguities that could be interpreted differently by different stakeholders?
  • Completeness - Is the set of requirements as a whole complete? Are there any requirements missing?0
  • Consistency - Is the set of requirements consistent? Are there any conflicts between requirements in the set?

Documenting Requirements Elicitation

• The requirements document proposed by Robertson and Robertson, provided in template form on the Volere web site:

• An alternative format proposed by Bruegge and DuToit:

• See also the Software Engineering Project Report Template developed for CS 440 at UIC, part II

4.6 - ARENA Case Study

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