Requirements Overview

Last updated: Mar. 29, 2006

Objectives:

• Describe the basic Requirements concepts and how they affect Analysis and Design

• Demonstrate how to read and interpret the artifacts of Requirements that are used as a starting point for Analysis and Design

Requirements in Context:

• The Business Modeling discipline provides organizational context for the system. This is the context in which the requirements are defined and analyzed.

• The purpose of the Requirements discipline is:

  • To establish and maintain agreement with the customers and other stakeholders on what the system should do.

  • To provide system developers with a better understanding of the system requirements.

  • To define the boundaries of (delimit) the system.

  • To provide a basis for planning the technical contents of iterations.

  • To provide a basis for estimating cost and time to develop the system.

  • To define a user-interface for the system, focusing on the needs and goal of the users.

• The Analysis and Design discipline gets its primary input the (Use-Case Model and the Glossary) from Requirements. Flaws in the Use-Case Model can be discovered during Analysis and Design; change requests are then generated, and applied to the Use-Case Model.

Relevant Requirements Artifacts:

• The Use-Case Model:

  • The Use-Case Model describes what the system will do. The Use-Case Model serves as a contract between the customer, the users, and the system developers. It allows customers and users to validate that the system will become what they expected and allows system developers to ensure that what they build is what is expected.

  • The Use-Case Model consists of use cases and actors. Each use case in the model is described in detail, showing step-by-step how the system interacts with the actors and what the system does in the use case.

  • The Use-Case Specification is the document where all of the use-case properties are documented (for example, brief description and use-case flows of events).

• The Glossary defines a common terminology for all models and contains textual descriptions of the required system.

• The Supplementary Specification contains those requirements that do not map to a specific use case (for example, nonfunctional requirements). The Supplementary Specification is an important complement to the Use-Case Model. Together they capture all requirements (functional and nonfunctional) that need to be described for a complete System Requirements Specification.

What Is System Behavior?

• System behavior is how a system acts and reacts.

  • It is the outwardly visible and testable activity of a system

• System behavior is captured in use cases.

  • Use cases describe the system, its environments, and the relationship between the system and its environment.

Major Concepts in Use-Case Modeling:

• An actor represents a coherent set of roles that users of the system play when interacting with these use cases. Typically, an actor represents a human, a hardware device, or some other external system. In UML 2, actors should be named whenever possible.

• A use case is a sequence of actions a system performs to yield an observable result that is of value to a particular actor. A use case describes what a system does, but it does not specify how it does it. Whenever space permits, put the name of the use case inside the icon.

What Is a Use-Case Model?

• A model that describes a system's functional requirements in terms of use cases

• A model of the system's intended functionality (use cases) and its environments (actors)

• A Use-Case Diagram

• Because it is a very powerful planning instrument, the Use-Case Model is generally used in all phases of the development cycle.

  • When the customer approves the Use-Case Model, it's a mutual understanding with the development team of what the customer wants. You can use the model to discuss the system with the customer during development.

  • Potential users use the Use-Case Model to better understand the system.

  • Designers use it as a basis for their work and to get a system overview.

  • Testers use it to plan testing activities (use case and integration testing) as early as possible.

  • Those developing the next version of the system use it to understand how the existing version works.

  • Documentation writers use the use cases as a basis for writing the system user guides.

  • The architect uses the Use-Case Model to identify architecturally significant functionality.

  • The manager uses it to plan and follow up on use-case modeling and subsequent design.

What Are the Benefits of a Use-Case Model?

• Communication with the end users and domain experts:

  • Provides buy-in at an early stage of system development.

  • Ensures a mutual understanding of the requirements.

• Identification of system users and what the systems should do:

  • Establishes the requirements for the system interfaces.

  • The Use-Case Model is also used to identify the actors that interact with the system.

• Verification that all requirements have been captured:

  • Ensures that the development team understands the requirements.

Use-Case Specifications:

• The use-case properties may be documented in use-case specifications, which can include the items listed below:

  • Brief description describes the role and purpose of the use case.

  • Flow of events are textual descriptions of what the system does with regard to the use case. There can be multiple flows of events －for example, a basic flow and alternative flows.

  • Relationships are associations, The use case can include and extend relationships that the use case participates in.

  • Activity diagrams can be used to illustrate the structure of the flow of events.

  • Use-case diagrams can be used to show the relationships involving the use case.

  • Special requirements is a textual description that collects all use-case requirements, like nonfunctional requirements, that are not considered in the Use-Case Model, yet need to be taken care of during design or implementation.

  • Pre-conditions define a constraint on the system regarding when the use case may start.

  • Post-conditions define a constraint on the system that applies after the use case has terminated.

  • Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen captures from a user-interface prototype.

Use-Case Flow of Events:

• Has one normal, basic flow

• Several alternative flows

  • Regular variants

  • Odd cases

  • Exceptional flows for handling error situations

• Guidelines for the flow of events. Specify that the content must:

  • Detail the flow of events. All "what" questions should be answered. Remember that test designers will use this text to identify test cases.

  • Describe how the use case starts and ends.

  • Describe the flow of events, not only the functionality. To reinforce this, start every action with "When the actor...."

  • Describe only the events that belong to the use case and not what happens in other use cases or outside of the system.

  • Describe the data exchanged between the actor and the use case.

  • Avoid describing the details of the user interface unless they are needed to provide an understanding the behavior of the system.

  • Avoid vague terminology such as "for example", "etc.," and  "information."

What Is a Scenario?

• A scenario  is an instance of a use case. It is one flow through a use case.

• How many scenarios are needed?

  • As many as one needs to understand the system being developed. You must elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be used to understand, as well as to validate, the use-case flows of events. Some people write scenarios first and extract use cases, while others find use cases first and validate those use cases by writing scenarios.

• Scenarios make excellent test cases.

What Is an Activity Diagram?

• An activity diagram in the Use-Case Model can be used to capture the activities in a use case.

• It is essentially a flow chart, showing flow of control from one activity or action to another.

• Example:

• An activity diagram may include the following elements:

  • Activity/Action represents the performance of a step within the workflow.

  • Transitions show the activity/action that follows.

  • Decisions evaluate conditions defined by guard conditions. These guard conditions determine which of the alternative transitions will be made and, thus, which activities are performed. You may also use the decision icon to show where the threads merge again. Decisions and guard conditions allow you to show alternative threads in the workflow of a use case.

  • Synchronization bars show parallel sub-flows. They allow you to show concurrent threads in the workflow of a use case.

• An activity diagram may be partitioned using solid vertical lines. Each partition should represent a responsibility for part of the overall workflow, carried by a part of the organization.

  • Example: sales process

Glossary:

• There is one Glossary for the system. This documents is important to many developers, especially when they need to understand and use the terms that are specific to the project. The Glossary is used to facilitate communications between domain experts and developers.

• The Glossary is developed primarily during the Inception and Elaboration phases, because it is important to agree on a common terminology early in the project. In Inception and Elaboration, it is used by domain experts (for example, business analysts) to explain all the domain-specific terminology used in their use cases. In Elaboration and Construction, developers use the Glossary to explain technical terms used in the other four models.

• Contents of the Glossary:

  • Introduction: Provides a brief description of the Glossary and its purpose.

  • Terms: Define the term in as much detail as necessary to completely and unambiguously characterize it.

Supplementary Specification:

• The nonfunctional requirements and functional requirements not captured by the use cases are included in the Supplementary Specifications.

  • Functionality: List of the functional requirements that are general to many use cases.

  • Usability: Requirements that relate to, or affect, the usability of the system. Examples include ease-of-use requirements or training requirements that specify how readily the system can be used by its actors.

  • Reliability: Any requirements concerning the reliability of the system. Quantitative measures such as mean time between failure or defects per thousand lines of code should be stated.

  • Performance: The performance characteristics of the system. Include specific response times. Reference related use cases by name.

  • Supportability: Any requirements that will enhance the supportability or maintainability of the system being built.

  • Design Constraints: Any design constraints on the system being built.

• Supplementary Specifications:

  • are initially considered in the Inception phase as a complement to defining the scope of the system.

  • are refined in an incremental fashion during the Elaboration and Construction phases.

Checkpoints:

• Requirements: Use-Case Model

  • Is the Use-Case Model understandable?

  • By studying the Use-Case Model, can you form a clear idea of the system's functions and how they are related?

  • Have all functional requirements been met?

  • Does the Use-Case Model contain any superfluous behavior?

• Requirements: Actors

  • Have all the actors been identified?

    • You will not be able to do this fully until you have found and described all the use cases.

  • Is each actor involved with at least on use case?

    • Remove any actors not mentioned in the use-case descriptions or that have no associations with a use case.

  • Is each actor really a role? Should any be merged or split?

    • If any actors play similar roles in relation to the system, they should be merged into a single actor. If a particular actor will use the system in several completely different ways, or has several completely different purposes for using the use case, then there should probably be more than one actor.

  • Do two actors play the same role in relation to a use case?

    • If two actors play the same role in relation to a use case, then actor-generalizations should be used to model their generalized behavior.

  • Do the actors have intuitive and descriptive names? Can both users and customers understand the names?

• Requirements: Use-Cases

  • Is each use case involved with at least one actor

    • A use case that does not interact with an actor is superfluous. You should remove it.

  • Is each use case independent of the others?

    • If two use cases are always activated in the same sequence, you should probably merge them into one use case.

  • Do any use cases have very similar behaviors or flows of events?

    • Use cases that have very similar behaviors or flows of events, or will be similar in the future, should be merged into a single use case. This makes it easier to introduce future change.

    • If some part of the flow of events is already part of another use case, the sub-flow should be extracted and then be included by all of the use cases in question.

  • Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage?

  • Do customers and users alike understand the names and descriptions of the use cases?

• Requirements: Use-Case Specifications

  • Is it clear who wants to perform a use case?

  • Is the purpose of the use case also clear?

  • Does the brief description give a true picture of the use case?

  • Is it clear how and when the use case's flow of events starts and ends?

  • Does the communication sequence between actor and use case conform to the user's expectations?

  • Are the actor interactions and exchanged information clear?

  • Are any use cases overly complex?

    • If you want your Use-Case Model to be easy to understand, you might have to split up complex use cases. A use case that contains disparate flows of events will be very difficult to understand and to maintain. It is best to divide such use cases into two or more separate ones.

• Requirements: Glossary

  • Does each term have a clear and concise definition?

  • Is each glossary term included somewhere in the use-case descriptions?

  • Are terms used consistently in the brief descriptions of actors and use cases?