Chapter 3 Understanding Requirements

Chapter 3 Understanding Requirements
Vision Use-Case Modeling Software Requirements Specification Requirements Management Case Study and Project

Requirements

3.1 Requirements What is Requirements Types of Requirements Requirements Documents

What is requirement? Requirements are capabilities and conditions to which the system (and more broadly, the project) must conform. [JBR99]. The purpose of Requirements is: 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 goals of the users.

Requirements Factors on challenged software projects
37% of factors related to problems with requirements,

Requirements Management
Requirements management is a systematic approach to eliciting, organizing, and documenting the requirements of the system establishing and maintaining agreement between the customer and the project team on the changing requirements of the system. Keys to effective requirements management include maintaining a clear statement of the requirements, along with applicable attributes for each requirement type traceability to other requirements and other project artifacts.

Types of Requirements – FURPS+
Functional features, capabilities, security. Usability human factors, help, documentation. Reliability frequency of failure, recoverability, predictability. Performance response times, throughput, accuracy, availability, resource usage. Supportability adaptability, maintainability, internationalization, configurability.

Types of Requirements – FURPS+
The "+" in FURPS+ indicates ancillary and sub-factors, such as: Implementation resource limitations, languages and tools, hardware, ... Interface constraints imposed by interfacing with external systems. Operations system management in its operational setting. Packaging Legal licensing and so forth.

Types of Requirements – RUP
Requirements are categorized as functional (behavioral) or non-functional (everything else); Functional Requirements Functional requirements are explored and recorded in the Use-Case Model the system features list of the Vision artifact. Non-functional Requirements Other requirements can be recorded in the use cases they relate to, or in the Supplementary Specifications artifact.

Requirement Documents
Vision The Vision artifact summarizes high-level requirements that are elaborated in these other documents. The Vision is a general vision of the core project's requirements, and provides the contractual basis for the more detailed technical requirements. Include: Problem Statement User or Stakeholder Descriptions Product Overview Features Constraints

Requirement Documents
SRS (Software Requirements Specification) Functional requirements Use case Model Non-functional requirements Supplementary Specification Glossary records and clarifies terms used in the requirements. also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth User-Interface Prototype Prototypes are a mechanism to clarify what is wanted or possible.

Requirement Artifacts in UP

Vision

3.2 Vision Introduction Template Example How to develop Vision

Vision - Introduction The Vision document provides
a complete vision for the software system under development and supports the contract between the funding authority and the development organization. The vision document is written from the customers' perspective, focusing on the essential features of the system and acceptable levels of quality. The Vision should include a description of what features will be included as well as those considered but not included. It should also specify operational capacities (volumes, response times, accuracies), user profiles (who will be using the system), and inter-operational interfaces with entities outside the system boundary, where applicable. The Vision document provides the contractual basis for the requirements visible to the stakeholders.

Vision - Introduction The Vision document
is created early in the inception phase, and it is used as a basis for the Business Case and the first draft of the Risk List serves as input to use-case modeling, and is updated and maintained as a separate artifact throughout the project.

Vision - Introduction Purpose of Vision
Gain agreement on what problems need to be solved. Identify stakeholders to the system. Define the boundaries of the system. Describe primary features of the system.

Vision - Template for small project
1. Introduction 2. Positioning 2.1 Problem Statement 2.2 Product Position Statement 3. Stakeholder and User Descriptions 3.1 Stakeholder Summary 3.2 User Summary Key High-Level Goals and Problems of the Stakeholders User-Level Goals 3.5 User environment

Vision - Template for small project
4. Product Overview 4.1 Product Perspective 4.2 Assumptions and Dependencies 5. Product Features 5.1 <aFeature> 5.2 <anotherFeature> 6. Other Requirements and Constraints

Vision - Commentary to Template
Problem Statement Provide a statement summarizing the problem being solved by this project. The following format may be used: The problem of [describe the problem] affects [the stakeholders affected by the problem] the impact of which is [what is the impact of the problem?] a successful solution would be [list some key benefits of a successful solution]

Product Position Statement Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. The following format may be used: For [target customer] Who [statement of the need or opportunity] The (product name) is a [product category] That [statement of key benefit; that is, the compelling reason to buy] Unlike [primary competitive alternative] Our product [statement of primary differentiation]

User Summary Present a summary list of all identified users. The following format may be used: Name Description Responsibilities Stakeholder [Name the user type.] [Briefly describe what they represent with respect to the system.] [List the user’s key responsibilities with regard to the system being developed; for example: captures details produces reports coordinates work and so on] [If the user is not directly represented, identify which stakeholder is responsible for representing the user’s interest.]

Product Perspective This subsection puts the product in perspective to other related products and the user’s environment. If the product is independent and totally self-contained, state it here. If the product is a component of a larger system, then this subsection needs to relate how these systems interact and needs to identify the relevant interfaces between the systems. One easy way to display the major components of the larger system, interconnections, and external interfaces is with a block diagram. System context diagram High-level deployment diagram

Product Features Use cases are not necessarily the only way one needs to express functional requirements. An alternative, a complementary way to express system functions is with features, or more specifically in this context, system features, System features are high-level, terse statements summarizing system functions. A system feature is "an externally observable service provided by the system which directly fulfills a stakeholder need" [Kruchten00]. Features are things a system can do. The point of system features in the Vision is to summarize the functionality, not decompose it into a long list of fine-grained elements. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how) they should be implemented. Avoid design. It is common to organize a two-level hierarchy

Other Requirements in the Vision In the Vision, system features briefly summarize functional requirements expressed in detail in the use cases. Likewise, the Vision can summarize other requirements (for example, reliability and usability) that are detailed in the Special Requirements sections of use cases, and in the Supplementary Specification (SS).

Vision - Example Course Registration System example NextGen example

Vision - How to develop Vision
Gain agreement on the problem being solved Identify stakeholders Define the system boundaries Identify constraints to be imposed on the system Formulate problem statement Define features of the system Evaluate your results

Vision - Checkpoints Have you fully explored what the "problem behind the problem" is? Is the problem statement correctly formulated? Is the list of stakeholders complete and correct? Does everyone agree on the definition of the system boundaries? If system boundaries have been expressed using actors, have all actors been defined and correctly described? Have you sufficiently explored constraints to be put on the system? Have you covered all kinds of constraints - for example political, economic, and environmental. Have all key features of the system been identified and defined? Will the features solve the problems that are identified? Are the features consistent with constraints that are identified?

3.3 Use-Case Modeling Key Concepts Use-Case Diagram Use-Case Specification Relationship between Use-case Checkpoints

Key Concepts In this section, we will discuss the key concepts of use-case modeling -- the actor and the use case, as well as what relationships can exist between them. We will also look at the artifacts that make up the use-case model: the use-case model, use-case specifications, and activity diagrams.

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 environment, and the relationship between the system and its environment. No system exists in isolation. Every system interacts with people or automated systems for some purpose. These interactions result in some sort of predictable result. This predictable result is system behavior. Use cases are the mechanism for capturing the desired behavior for the system that is under development, but do not specify how the behavior is to be implemented. The UML specifies a model for communicating system behavior, the use-case model.

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 environment (actors) Actors and use cases are discussed on the next several slides. Use this slide to set the context for that discussion. You might describe a use-case model as a menu. The person can place themselves in a role (actor) and see the options available to them on this system. A use-case model does NOT imply the order that use cases will execute. View Report Card A use-case model describes a system’s functional requirements in terms of use cases. It is a model of the system's intended functionality and its environment. The use-case model serves as a contract between the customer and the developers. 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, you know the system is what the customer wants. You can also use the model to discuss the system with the customer during development. Potential users use it 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's user guides. The architect uses the use-case model to identify architecturally significant functionality. The manager use it to plan and follow up on the use-case modeling and the subsequent design. Register for Courses Student Login

What Are the Benefits of a Use-Case Model?
Used to communicate with the end users and domain experts Provides buy-in at an early stage of system development Insures a mutual understanding of the requirements Used to identify Who interacts with the system and what the system should do The interfaces the system should have Used to verify All requirements have been captured The development team understands the requirements Yes, we are selling the concept of a use-case model here. Many of your students may not immediately recognize the need for the use-case model because it is so simple. This slide is intended to bring out some of the problems that this model will resolve. Feel free to add in your own experiences here. There are many ways to model a system, each of which may serve a different purpose. However, the most important role of a use-case model is to communicate the system's behavior to the customer or end user. Consequently, the model must be easy to understand. The Use-Case model is also used to identify the actors that interact with the system. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actors' needs, ensuring that the system will turn out to be what the users expected.

Major Concepts in Use-Case Modeling
An actor represents anything that interacts with the system. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. Actor 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 role that a human, a hardware device, or even another system plays with a system. 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. Use Case

What Is an Actor? Actors are not part of the system.
Actors represent roles a user of the system can play. They can represent a human, a machine, or another system. They can actively interchange information with the system. They can be a giver of information. They can be a passive recipient of information. Be sure that the class understands that an actor is NOT JUST A PERSON. An actor is anything that interacts with the system and is external to the system. Illustrate this concept by using the example of an ATM machine. Ask the class to identify some potential actors. Answers may include: bank customer, maintenance worker, bank teller, bank system, credit card system, and so on. Actor An actor can be defined as: Anything that exchanges data with the system and is external to the system. To fully understand the system's purpose you must know who the system is for. Different user types are represented as actors. An actor can be a user, external hardware, or another system. An actor may actively interchange information with the system, be a passive recipient of information, or can represent a human, a machine or another system. The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, which means they can be one and the same actor. In which case, each user constitutes an instance of the actor. In some situations, only one person plays the role modeled by an actor. For example, there may be only one individual playing the role of system administrator for a rather small system. The same user can also act as several actors. That is, the same person can take on different roles. Actors are EXTERNAL.

Useful Questions in Finding Actors?
Who will supply, use, or remove information? Who will use this functionality? Who is interested in a certain requirement? Where in the organization is the system used? Who will support and maintain the system? What are the system’s external resources? What other systems will need to interact with this one? Note that it is more useful to find actors before use cases. After you determine your audience (actors), you can determine the required functionality for your system. Actor Think about the individuals who will use the system. How can you categorize them? It is often a good habit to keep a few individuals (two or three) in mind and make sure that the actors you identify cover their needs. The following questions may be useful when identifying actors: Who will supply, use, or remove information? Who will use this functionality? Who is interested in a certain requirement? Where in the organization is the system used? Who will support and maintain the system? What are the system’s external resources? What other systems will need to interact with this one? There are several different aspects of a system's surroundings that you will represent as separate actors. Users who execute the system's main functions Users who execute the system's secondary functions External hardware the system uses Other systems interacting with the system

Focus on the Roles An actor represents a role that a human, hardware device, or another system can play. ? One individual can play many different roles. For example, in the ATM problem, the same person could play the role of bank customer and bank teller. The actor should reflect the role and not the person. The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, meaning they can be the same actor. In that case, each user constitutes an instance of the actor.

A User May Have Different Roles
Charlie Charlie as student as professor Professor Student For example, Charlie is a professor who also happens to be enrolled in a course as a student. Therefore, Charlie plays both a professor and a student role in the system. An instance of an actor represents an individual interacting with the system in a specific way.

Practice: Find the Actors
In the Course Registration System Requirements document, read the Problem Statement for the Course Registration case study. As a group, identify the following Actors Description of the actor Give the class a few minutes to read the problem statement, then guide them in this practice. A session may start as follows. What is an actor? Walk the class through the questions for identifying actors. When someone identifies an actor, have him/her describe the actor. Make sure the class stays within the scope of the problem statement. Avoid trying to discover actors for scenarios that are not described here.

Practice: Solution A person who is registered to take courses at the University Student Billing System The external system responsible for student billing At minimum, your students should have discovered these actors. The unabridged catalog of all courses offered by the University A person who is teaching classes at the University Course Catalog Professor The person who is responsible for the maintenance of the course registration system Registrar

What Is a Use Case? A sequence of actions a system performs that yields an observable result of value to a particular actor Use cases focus on WHAT the system does, not HOW it does it. A use case has a set of properties that includes a brief description, flow of events, special requirements, activity diagrams, and so on. These are discussed in more detail later in this module. Use cases are enclosed in the use-case model artifact. That is, use cases are properties of the use-case model. Use Case A use case can be defined as: A sequence of actions a system performs that yields an observable result of value to a particular actor. System performs. The system provides the use case. An actor communicates with a use-case instance of the system. An observable result of value. You can put a value on a successfully performed use case. A use case should ensure that an actor can perform a task that has an identifiable value. This is important to determine the correct level or granularity for a use case. Correct level refers to achieving use cases that are not too small. In certain circumstances, you can use a use case as a planning unit that includes individuals playing the role of an actor to the system. Actions. An action is a computational or algorithmic procedure. It is invoked either when the actor provides a signal to the system or when the system receives a time event. An action may imply signal transmissions to either the invoking actor or other actors. An action is atomic. That is, it is performed either entirely or not at all. A particular actor. The actor is key to finding the correct use case because the actor helps you avoid use cases that are too large. As an example, consider a visual modeling tool. There are two actors to this application: a developer, someone who develops systems using the tool as support and a system administrator, someone who manages the tool. Each of these actors has his own demands on the system and will require his own set of use cases.

Use Cases and Actors A use case models a dialog between actors and the system. A use case is initiated by an actor to invoke a certain functionality in the system. The communicates association can also be drawn in the other direction. A use case can initiate communication with an actor. Usually, this will occur with a non-human actor. Actor Use Case It is important to show how actors relate to the use case. Therefore, on finding a use case, establish the actors that will interact with it. To do this, you must define a communicates association that is navigable in the same direction as the transmission between the actor and the use case. Actors may be connected to use cases only by an association. An association between an actor and a use case indicates that the actor and the use case communicate with one another, each one able to send and receive messages. Communicates Association

How to Find Use Cases Answer the following questions to find use cases. For each actor you have identified, what are the tasks the system would be involved in? Does the actor need to be informed about certain occurrences in the system? Will the actor need to inform the system about sudden, external changes? What information must be modified or created in the system? The first use cases are preliminary, and you’ll have to change them a few times until they are stable. If the system's vision or requirements are deficient or if the system analysis is vague, the system's functionality will be unclear. Therefore, you must constantly ask yourself if you have found the right use cases. Furthermore, be prepared to add, remove, combine, and divide the use cases before you arrive at a final version. You better understand the use cases after you have described them in detail. The best way to find use cases is to consider what each actor requires of the system. Remember, the system exists only for its users and should be based on the users' needs. You will recognize many of the actors' needs through the functional requirements made on the system. The answers to these questions represent the flows of events that identify candidate use cases. Not all constitute separate use cases. Some may be modeled as variants of the same use case. It is not always easy to tell what is a variant and what is a separate and distinct use case. However, it will become clearer when you describe the flows of events in detail.

Naming the Use Case The name indicates what is achieved by its interactions with the actor(s). The name may be several words in length. No two use cases should have the same name. Register for Courses Try to avoid use cases that are too detailed. For example, don’t use a use case that is titled “Add Student Information,Delete Student Information, Modify Student Information.” Instead, use one titled “Maintain Student Information” that encompasses all of the sub-flows involved in maintaining student information. Note that this is a common trap many people fall in. It results in a use-case model that is overly complex and difficult to use. Login Each use case should have a name that indicates what is achieved by its interactions with the actor(s). The name may have to be several words to be understood. No two use cases can have the same name. Maintain Student Information

Use-Case Diagram

Use case diagram Captures system functionality as seen by users
Built in early stages of development Purpose Specify the context of a system Capture the requirements of a system Validate a system’s architecture Drive implementation and generate test cases Developed by analysts and domain experts

How Would You Read This Diagram?
Which use case comes first, Register for Courses or View Report Card? Of course, this is a trick question. You can’t make that assumption from looking at this model. It isn’t intended to show order. Why are there no arrow heads on the Course Catalog and Billing System communicates associations? Association relationships between actor classes and use case classes are used to indicate that the actor participates and communicates with the system containing the use case. Association relationships are denoted as solid lines or paths. Arrowheads may be used to indicate who initiates communication in the interaction. If an arrowhead points to a use case, the actor at the other end of the association initiates the interaction with the system. If the arrowhead points to an actor, the system initiates the interaction with the actor at the other end of the association. By Rational convention : - RU courses will show the initiating actor-to-use-case arrowhead only. - The use-case-to-actor arrowhead *may* be used if necessary, for clarification. - *NO* double-headed arrows (2-way communcation is assumed) View Report Card Student Maintain Professor Information Register for Courses Course Catalog Login Maintain Student Information Select Courses to Teach Answer the following questions: Which use cases will a student be able to perform? A professor? The Course Catalog? If Charlie is a student and professor, which use cases will he be able to execute? Describe the functionality of this system. Describe the actor relationships for the Close Registration and Select Courses To Teach use cases. What doesn’t this model say? Which use case needs to run first, Register for Courses or View Report Card? Registrar Professor Submit Grades Close Registration Billing System

Use Case Diagram - Example
User Management System Configuration Administrator Normal User User Authentication Query Project Management Project Manager Development Manager

Use-Case Specification

Use-Case Specifications
Name Brief description Flows of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams Use-Case Specifications ... Use-Case Model Actors Use Cases The flows of events is understood by the customer. The flow of events describes how and when the use case starts and ends, when the use case interacts with the actors, and the information exchanged between an actor and the use case. The flows of events does not describe user interface details. A use-case specification contains all textual information for a use case. A use-case report contains the properties of a use case, including diagrams. Note that a use-case report is a use-case specification AND diagrams. The use case has a set of properties as shown in the graphic. The use-case properties may be documented in use-case specifications, which may include: Brief description describes the role and purpose of the use case in a few lines. Flows of events are textual descriptions of what the system does with regard to the use case. There may be multiple flows of events, for example, a basic flow and alternative flows. Relationships are communicates-associations. The use case includes and extends 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 non-functional 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 for when the use case may start. Post-conditions define a constraint on the system for after the use case has terminated. Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen dumps from an user-interface prototype.

Use-Case Specifications - Flow of Events
A use case describes what a system (or a subsystem, class, or interface) does but it does not specify how it does it. You can specify the behavior of a use case by describing a flow of event in text clearly enough for outsider to understand it easily. When you write this flow of events, you should include how and when the use case starts and ends, when the use case interacts with the actors and what objects are exchanged, and the basic flow and alternative flow of the behavior.

Use-Case Flow of Events
Has one normal, basic flow Several alternative flows Regular variants Odd cases Exceptional flows handling error situations In the Maintain Student Information use case, there may be separate sub-flows for adding, deleting, and modifying student information. Don’t be too concerned with the exact definition “basic” versus “alternate or exception.” Readability and understandability are the key here. Note: The colors are not distinguishable in the black and white books. That’s Ok. The picture still provides value as the alternate flows are visible. A use case’s flow of events: Contains the most important information derived from use-case modeling work. Should describe the use case's flow clearly enough for an outsider to easily understand it. Should present what the system does, not how the system is designed to perform the required behavior. A use case’s Contents Guidelines: Details the flow of events. All "what“ questions should be answered. Remember that test designers will use this text to identify test cases. Describes how the use case starts and ends. Describes the flow of events, not only the functionality. To reinforce this, start every action with "When the actor. . .” Describes only the events that belong to the use case and not what happens in other use cases or outside of the system Describes the data exchanged between the actor and the use case. Does not describe the details of the user interface unless it is needed to understand the behavior of the system. Avoids vague terminology such as "for example", "etc. " and "information."

Use-Case Specifications - Scenarios
A use case actually describes a set of sequences in which each sequence in the set represents one possible flow through all those variations. A scenario is a specific sequence of actions that illustrates behavior. Scenarios are to use cases as instances are to classes, meaning that a scenario is basically one instance of a use case.

What Are Scenarios ? A scenario is an instance of a use case
A scenario is an instance of a use case. It is one flow through a use case. Each use-case will have a web of flows of events with a scenario being an instance of a particular flow of events. The scenario may involve the basic flow and any number of alternative flows in any number of combinations. In the above example, the bold lines highlight some possible scenarios for the basic and alternative flows previously described. How many scenarios are needed? Simple answer: As many as one needs to understand the system being developed. You should 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 activity to activity. Activity diagrams can also be used to model the workings of an operation, an object, business modeling, or anything that involves modeling the sequential steps in a computational process. This course will focus on using activity diagrams to model the flow of events in a use case. Flow of Events This use case starts when the Registrar requests that the system close registration. 1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress. 2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it. The workflow of a use case describes what needs to be done by the system to provide the value that the served actor is looking for. It consists of a sequence of activities that, together, produce something for the actor. The workflow often consists of a basic flow and one or several alternative flows. The structure of the workflow can be described graphically with the help of an activity diagram.

Example: Activity Diagram
Activity State [ delete course ] Decision Walk the students through the activity diagram and explain each component (decision, fork, join, and so on). Delete Course [ add course ] Select Course Concurrent threads Synchronization Bar (Fork) Check Check Schedule Pre-requisites Transition Guard Condition Synchronization Bar (Join) An activity diagram may include the following elements: Activity states, which represent the performance of an activity or step within the workflow. Transitions show what activity state follows after another. 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 used to show parallel sub-flows. Synchronization bars allow you to show concurrent threads in the workflow of a use case. [ checks completed ] [ checks failed ] Assign to Resolve course conflicts [ student added to the course ] Update schedule

Use-Case Specifications - Example
- User Management 1. Brief Description This use case is for adding and deleting users. When adding user, the privilege of the user will be assigned Basic Flow B1. Start of use case Actor chooses User Management in main screen B2. Prompt welcome screen System shall prompt actor the user management welcome screen A1. Choose delete user B3. Choose add user Actor chooses Add User B4. Prompt add user screen System shall prompt actor the add user screen which needs actor to input some information These information include: User Name, User ID, User Password, User Role B5. Submit Actor inputs the information and submits the screen E1. User ID already exists E2. Not enough information B6. Prompt success System shall prompt actor success information.

Use-Case Specifications - Example
3. Alternative Flows A1. Choose Delete User From B2. Prompt welcome screen A1.1 Choose delete Actor chooses delete user. A1.2 Prompt delete user screen System shall prompt actor the delete user screen In this screen, system shall lists all the user ID stored in system. A1.3 Choose user to delete Actor chooses the user ID to delete and submit this screen E3. No user ID chosen A1.4 Prompt success System shall prompt actor success information. 4. Exception Flows E1. User ID already exists From B5. Submit, The User ID actor inputs has already existed in the system. The system shall prompt actor to try another User ID。 E2. Not enough information From B5. Submit, If actor does not input all the information, system can not add a user. The system shall prompt actor to input all the information. E3. No user ID chosen From A1.3 Choose user to delete, If actor does not choose a user to delete before submitting the screen, the system shall prompt actor an error that he/she should choose a user to delete.

Relationship between Use-Case

Relationship between Use-case (optional)
include extend generalization

Relationship between Use-cases - include
• <<include>> – An include relationship from use case A to use case B indicates that an instance of the use case A will also contain the behavior as specified by B. The behavior is included at the location which defined in A. Offer a line of credit Submit a load request Perform credit check <<include>>

<<include>>: Functional Decomposition Problem: w A function in the original problem statement is too complex to be solvable immediately Solution: w Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases ManageIncident CreateIncident HandleIncident CloseIncident <<include>>

<<include>>: Reuse of Existing Functionality Problem: w There are already existing functions. How can we reuse them? Solution: w The include association from a use case A to a use case B indicates that an instance of the use case A performs all the behavior described in the use case B (“A delegates to B”) Example: w The use case “ViewMap” describes behavior that can be used by the use case “OpenIncident” (“ViewMap” is factored out) Note : w The base case cannot exist alone. It is always called with the supplier use case Base Usecase AllocateResources OpenIncident ViewMap <<include>> Supplier Usecase

Relationship between Use-cases - extend
<<extend>>– An extend relationship from use case A to use case B indicates that an instance of use case B may be augmented (subject to specific conditions specified in the extension) by the behavior specified by A. The behavior is inserted at the location defined by the extension point in B which is referenced by the extend relationship. Request additional credit information <<extend>> Evaluate loan request Refer loan request to loan committee <<extend>>

Relationship between Use-cases - extend
Problem: w The functionality in the original problem statement needs to be extended. Solution: w An extend association from a use case A to a use case B indicates that use case B is an extension of use case A. Example: w The use case “ReportEmergency” is complete by itself , but can be extended by the use case “getHelp” for a specific scenario in which the user requires help Note : w In an extend assocation, the base use case can be executed without the use case extension getHelp FieldOfficer ReportEmergency <<extend>>

Relationship between Use-cases - Generalization
With the introduction of UML 1.3, a new relationship between use cases was introduced - generalization Generalization – A generalization from use case A to use case B indicates that A is a specialization of B. Withdraw funds Withdraw from savings Withdraw from checking Request credit card advance

Relationship between Use-cases - Generalization
Problem: w You have common behavior among use cases and want to factor this out. Solution: w The generalization association among use cases factors out common behavior. The child use cases inherit the behavior and meaning of the parent use case and add or override some behavior. Example: w Consider the use case “ValidateUser”, responsible for verifying the identity of the user. The customer might require two realizations: “CheckPassword” and “CheckFingerprint” Parent usecase Child usecase CheckPassword ValidateUser CheckFingerprint

Checkpoints

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? Is the division of the model into use-case packages appropriate? Complete checklists are provided in the online Rational Unified Process. A normal system has 20 to 50 use cases. A very large system has no more than 100 use cases. The number of use cases is more a measure of the complexity of the interaction between the system and actors. A big, but simple, system may have a few use cases, but a small system (that may be complex to build) may have lots of use cases. The number of use cases a project may initially identify may be large (because they are doing functional decomposition) The idea of fewer use cases helps to push them towards the real usage of use cases - thinking of functionality rather than algorithms when doing functional requirements analysis.

Checkpoints: Requirements: Actors
Have all the actors been identified? Is each actor involved with at least one use case? Is each actor really a role? Should any be merged or split? Do two actors play the same role in relation to a use case? Do the actors have intuitive and descriptive names? Can both users and customers understand the names?

Checkpoints: Requirements: Use-Cases
Is each use case involved with at least one actor? Is each use case independent of the others? Do any use cases have very similar behaviors or flows of events? 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? Note: These checkpoints really only apply to concrete use cases, not use cases that extend other use cases or are used by other use cases, but use-case uses and extends were not covered in this course for scoping reasons.

Checkpoints: Requirements: Use-Case Specifications
Is it clear who wishes 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?

Review: Requirements Overview
What are the main artifacts of Requirements? What are the Requirements artifacts used for? What is a use-case model? What is an actor? What is a use case? List examples of use case properties. What is the difference between a use-case and a scenario? What is a supplementary specification and what does it include? What is a glossary and what does it include? The following page numbers will help the instructor find the answers to the review questions: Question 1: p. 5 Question 2: pp. 4-5 Question 3: p. 11 Question 4: p. 9 Question 5: p. 9, 14 Question 6: pp Question 7: p. 23 Question 8: p. 20

3.4 Software Requirements Specification
Identifying other requirements Supplementary Specifications Glossary

Supplementary Specifications

Supplementary Specification
Functionality Usability Reliability Performance Supportability Design constraints Those non-functional requirements that can be tied to a particular use case should be documented in the use case “special requirements” property. The Rational Unified Process ships with templates for the supplementary specification. Supplementary Specification The non-functional requirements and functional requirements not captured by the use cases are included in the supplementary specifications. The Supplementary Specifications include constraints on the implementation. 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 go hand-in-hand with the use-case model, implying that: They are initially considered in the inception phase as a complement to defining the scope of the system. They are refined in an incremental fashion during the elaboration and construction phases.

Supplementary Specification - Example
Review the Supplementary Specification provided in the Course Registration Requirements Document Direct the Students to the Supplementary Specification in the Course Registration Requirements document. Give them an opportunity to read the it themselves and discuss any questions, comments, issues. Highlight the different sections and stress that your project may include their own specific sections. Emphasize those non-functional requirements that will end up being modeled on interaction diagrams.

Glossary

Glossary Glossary Course Registration System Glossary 1. Introduction
The Glossary does not document things purely in the solution space, such as mechanisms, key abstractions related only to the solution space, architectural patterns being used, and the like. Do not overload the Glossary with those sorts of things - it’s primarily a ‘user-oriented’ document. The SAD is better at communicating the common architectural “house rules”. The Rational Unified Process ships with a template for the Glossary. Course Registration System Glossary 1. Introduction This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. 2. Definitions The glossary contains the working definitions for the key concepts in the Course Registration System. 2.1 Course: A class offered by the university. 2.2 Course Offering: A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered. 2.3 Course Catalog: The unabridged catalog of all courses offered by the university. Glossary The Glossary defines important terms used in the project. There is one Glossary for the system. This document 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/Elaboration it is used by domain experts (e.g., business analysts) to explain all the domain-specific terminology used in their use cases. In Elaboration/Construction, developers use the Glossary to explain technical terms used in the other four models. A system analyst is responsible for the integrity of the Glossary, ensuring that the Glossary is produced in a timely manner and is continuously kept consistent with the results of development. The above is just a sample outline for the Glossary. Not all of these elements need to be in the Glossary. A project needs to establish the template to be used on that particular project. Introduction: 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.

Glossary - Example Review through the Glossary provided in the Course Registration Requirements Document Direct the Students to the Glossary in the Course Registration Requirements document. Give them an opportunity to read it themselves and discuss any questions, comments, issues.

3.5 Requirements Management
Making sure you Solve the right problem Build the right system By taking a systematic approach to eliciting organizing documenting and managing the changing requirements of a software application.

Aspects of Requirements Management
Analyze the Problem Understand User Needs Define the System Manage Scope Refine the System Definition Build the Right System

Map of the Territory Traceability Problem Problem Space Needs
Solution Space Features Traceability The Product To Be Built Use Cases and Software Requirements Managing requirements involves the translation of stakeholder requests into a set of key stakeholder needs and system features. These in turn are detailed into specifications for functional and non-functional requirements. Detailed specifications are translated into test procedures, design, and user documentation. Traceability allows us to: Assess the project impact of a change in a requirement Assess the impact of a failure of a test on requirements (i.e., if test fails, the requirement may not be satisfied) Manage the scope of the project Verify that all requirements of the system are fulfilled by the implementation Verify that the application does only what it was intended to do Manage change Test Procedures Design User Docs

3.6 Case Study and Project Inception Phase Case Study - CRS

Inception Phase

Inception Phase Inception Phase : Define the scope of the project and develop business case The primary objectives of the inception phase include: Establishing the project's software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not. Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design trade-offs. Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios Estimating the overall cost and schedule for the entire project. Estimating potential risks. Preparing the supporting environment for the project.

What Artifacts May Start in Inception?
Comment Vision and Business Case Describes the high-level goals and constraints, the business case, and provides an executive summary. Use-Case Model Describes the functional requirements, and related non-functional requirements. Supplementary Specification Describes other requirements. Glossary Key domain terminology. Risk List & Risk Management Plan Describes the business, technical, resource, schedule risks, and ideas for their mitigation or response. Prototypes and proof-of-concepts To clarify the vision, and validate technical ideas. Iteration Plan Describes what to do in the first elaboration iteration. Phase Plan & Software Development Plan Low-precision guess for elaboration phase duration and effort. Tools, people, education, and other resources. Development Case A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project.

Inception Phase - a suggested sequence
1. Write a brief first draft of the Vision. 2. Identify user goals and the supporting use cases. 3. Write some use cases and start the Supplementary Specification. 4. Refine the Vision, summarizing information from these.

Checkpoint: What Happened in Inception?
Inception is a short step to determine basic feasibility, risk, and scope. Some likely activities and artifacts in inception include: a short requirements workshop most actors, goals, and use cases named most use cases written in brief format; 10-20% of the use cases are written in fully dressed detail to improve understanding of the scope and complexity. most influential and risky quality requirements identified version one of the Vision and Supplementary Specification written risk list technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements user interface-oriented prototypes to clarify the vision of functional requirements recommendations on what components to buy/build/reuse, to be refined in elaboration high-level candidate architecture and components proposed plan for the first iteration candidate tools list

Sample requirements effort across the early iterations

Case Study (Covered in GCIS501)

Case Study - Course Registration System
Vision SRS - Use Case Model SRS - Supplementary Specification SRS - Glossary

Project – Inception Phase

Project - Requirements
Work as a team (max 3 person) Select topic Write the following Requirements artifacts: Vision SRS Use-case model (Use-case diagram, Use-case specification, Activity Diagram) Supplementary specification Glossary User Interface (optional) Have the students review each of the artifacts and note any questions, comments, and/or concerns. Then discuss the comments as a group. During the artifact discussion, I recommend that you display the Use-case model main diagram from the Payroll System Rose model, and then walk through with the students to make sure that they understand the system they will be working with in the exercises throughout the course. Some students may question why Printer is included as an actor. See the Instructor Best Practices document for a discussion of the rationale.

Chapter 3 Understanding Requirements

Similar presentations

Presentation on theme: "Chapter 3 Understanding Requirements"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 3 Understanding Requirements

Similar presentations

Presentation on theme: "Chapter 3 Understanding Requirements"— Presentation transcript:

Similar presentations

About project

Feedback