Requirements Management with Use Casessceweb.sce.uhcl.edu/helm/READ_ReqEngSWEN5130/my... · Requirements Management . with Use Cases. Module 7: Refine the System Definition. ... Define

Requirements Management with Use Cases

Module 7: Refine the System Definition

Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 2

Where Are We in The Requirements Workflow?

Presenter

Presentation Notes

Where does the Refine the System Definition workflow detail fit in our development process? In the Rational Unified Process, the workflow detail called “Refining the System Definition” represents activities that we might undertake to further refine the set of requirements for our system. Where is this done in your own software development process?


Refine the System Definition: Module Objectives Decide on the detailed software requirements Define the Software Requirements Specification Detail the use cases Detail the declarative requirements Learn qualities of good requirements

Presenter

Presentation Notes


Refine the System Definition: Activities and Artifacts

Presenter

Presentation Notes

In RUP, the purpose of this workflow detail is to: Describe the use case's flow of events in detail Detail Supplementary Specifications Model and prototype the user interface Refining the System begins with use cases outlined, actors at least described briefly, and a revised understanding of the project scope reflected in the re-prioritized features of Vision that is believed to be achievable by fairly firm budgets and dates. The output of this workflow is a more in-depth understanding of the system functionality expressed in detailed use cases, revised and detailed Supplementary Specifications, and definitions of user-interface elements.


Refine the System: Software Requirements Focus

Problem

Solution Space

Problem Space

Needs

Features

SoftwareRequirements

Test Procedures Design User

Docs

The Product To Be Built

Presenter

Presentation Notes

Now we will move into the heart of the requirements -- the software requirements. Our goal is to express the required behavior and conditions at a level that implementers and testers can use to drive the further development of the system to be built.


What Do Software Requirements Specify?

SystemInputs Outputs

FunctionsPerformance

Environments

Presenter

Presentation Notes

A requirement is a capability or condition to which the system must conform. Software requirements provide an almost “black-box” definition of the system. They define only those externally observable “what’s” of the system, not the “how’s”. Of course, there will have to be enough of the “How” specified to build the right system, but these should be identified as design constraints.


Features Drive Software Requirements

Feat 63 - the defect tracking system will provide trending information to help the project manager assess project status

Trending information will be charted with a line graph showing time on the x axis, and number of defects found on the y axis.

Trending periods can be entered in units of days, weeks or months.

An example trend reportis shown in Figure 1:

Print StatusReportOperator Project

Manager

Presenter

Presentation Notes

The features that we derived for our system (see Module 5) will drive the definition of the software requirements. The software requirements may be specified in many forms, including use cases and declarative sentences.


Specifying the Software Requirements

Features

SoftwareRequirements

Needs

The Software Requirements Specification (SRS) package defines complete external behavior and characteristics of the system to be built

Vision Document

Supplementary SpecificationsUse-Case Model

SRS SRS Package

Presenter

Presentation Notes

The SRS (Software Requirement Specification) is a package that contains specifications of software requirements. The specifications are written to a level of detail for handing off to the Designers, Testers, and User Documentation writers. We will assume that the requirements are “jointly” developed and agreed upon by the customer and the development team, rather than imposed (or externally specified) by the customer. It is important to adhere to some level of standards for consistency, for example, having standard document templates and standards for the database repository. The Requirements Management Plan is the place to record the standards and styles that will be used.


Roles of the SRS Package

Basis of communication between all parties Contractual agreement between parties Basis for development: design, implement, test

Supplementary SpecificationsUse-Case Model

SRS SRS Package

Presenter

Presentation Notes

Our primary goal is to have communication between the development team (Design, QA, Documentation) and the customer organization, so it is necessary that it be readable and understandable by all parties.


Who Uses the SRS Package? Client team Customer: approve what system should do Users: understand what system should do

Developer team Use-case and requirements specifiers:

refine software requirements Designers: find design classes Testers: use as basis for test cases Project Manager: manage the project Technical Writers: write user’s guide

Remember the SRS is for people to read, not for computers

Presenter

Presentation Notes

Before we go into the details on how to write the requirement specifications in the SRS package, we must know who will read and use it. You may find your readers on the list, or maybe you will have others. The readers vary from system to system (project to project). It is important to keep the actual readers in mind throughout the work in the document in order to focus on the right: Contents Level of detail Organizational method (use cases and declarative) Way of describing (words to use) Physical location (printed document or repository or web page)


1. Introduction1.1 Purpose1.2 Scope1.3 Definitions, Acronyms, and Abbreviations1.4 References1.5 Overview

2. Overall Description2.1 Use-Case Model Survey2.2 Assumptions and Dependencies

3. Specific Requirements3.1 Use Case Reports

3.1.1 <Use Case 1>3.1.2 ...

3.2 Supplementary Specifications3.2.1 Usability Requirements3.2.2 …

4. Supporting InformationAppendicesIndex

What Is In An SRS Package?

TP7:SRS Package Template

Presenter

Presentation Notes

This is a template for a SRS package. It includes introductory and overview information, and all software requirements. Some of the software requirements will be in use cases, in the section called Use Case Reports. Some of the requirements will be in declarative form, in the section called Supplementary Specifications. Section 2, the Overall Description, consists of the Use-Case-Model Survey, and any other Assumptions and Dependencies. The Use-Case-Model Survey gives the overview of the use-case model: the actors and use cases (it was described in Module 5). Section 3, the Specific Requirements, consists of the Use-Case Reports and the Supplementary Specifications. Each Use-Case Report fully details a particular use case. The Supplementary Specifications describe all the software requirements that are not part of a particular use case. We’ll give more detail on the Use Case Reports and the Supplementary Specifications later in this module. Note that the SRS template lays out the content and logical ordering of the SRS package. There will probably be a document that gives the overview of the SRS package, but many of its sections may contain pointers to the location of an item in the SRS. For example, a use-case report section may contain pointers to the URL’s where its use-case diagrams and textual representations can be found. For more details on this approach, see the “Modern SRS” outline and discussion in Managing Software Requirements, by Leffingwell and Widrig. An SRS template is also included in your Student Handouts.


Documents

ProjectRepository

Where to Store The Items in The SRS Package?

The mechanics of where to store depend onAvailable toolsDeveloper environment and preferencesClient environment and preferences

Presenter

Presentation Notes

The SRS package may not exist entirely in one document. Items in the SRS package may reside in other documents, in a requirements repository or in other locations. Items may be accessible through a web-based server, on a fttp server, or in printed form. The System Analyst must decide where each item of the SRS is actually stored and how the users of the SRS will access each item. For example, a use-case report may consist of a textual document, a use-case diagram, and a sketch of a user interface; each may have been created with a different tool, stored at a different location, and accessed with a different access path. Or, for ease of accessibility, all pieces of the use case report may be gathered into a single printed document which is attached as an appendix to the SRS document. How does the Analyst decide how to store and access the items of the SRS package? It varies greatly from organization to organization. When deciding on form and location of SRS items, consider: what tools are available, and preferences and environment of both the client and developer organizations. Many organizations are most comfortable with printed documents that the reviewers can literally sign off on. Documents have many advantages, including: the use of standardized templates; and, the consolidation of information in a single item. Other organizations may want to keep their requirements in a database. The advantages of a requirements database include: attributes and traceability links can be stored along with each requirement; and, the database can be queried. For example, a manager could query the database to find out which high-priority requirements have not yet been approved.


How to Specify Functional Requirements ?

Use Cases

Use Cases

Declarative Statements

The system shall …The system shall …The system shall ...

?Which one to choose?

Presenter

Presentation Notes

Use-case modeling is relatively new. Many organizations are not yet modeling requirements with use cases. They feel they have to decide between use-case modeling and the traditional approach of using declarative statements of requirements.


How to Specify Functional Requirements ? Recommendation Use Both Use Cases and Declarative Statements

• Both are necessary to understand any system of significant complexity

Preference for uses cases, where appropriate

Use Cases

Use Cases


The system shall …The system shall …The system shall ...+

Presenter

Presentation Notes

There is no one right answer to the question of how to write requirements about system functionality. For many projects, the answer is a mix: some functional requirements will be expressed in use cases, and others will be expressed in declarative statements. How does the Analyst decide when to use use cases and when to use declarative statements of requirements? The mix will vary greatly from organization to organization and from project to project. When deciding whether particular behavior is best modeled with use cases, consider: Context of the application and the project Skills and comfort level of the developer organization Client preferences and environment Risks in your project and how best to address those risks


SRS Variations For Functional Requirements

Use CasesDeclarative Statements Use Cases


Situation 1 Situation 2

The system …The system …

The system …The system …The system …



Presenter

Presentation Notes

How much of the functional requirements will you specify with use cases and how much in declarative statements? It varies from project to project. Some projects have mostly use cases and only a few declarative statements. In other projects, it is just the opposite. Our preference is to model functional requirements with use cases, because of the advantages we have mentioned throughout the course. For example, for the ATM system, the Withdraw Cash use case shows the whole sequence of system behavior that occur when a user withdraws cash. Each system behavior is a functional requirement. The sequence gives a context to the functional requirements. But not all behavior is best modeled with use cases. For example, you could describe functional requirements for a Java compiler with use cases, but standard “BNF” form may be more concise. For another example, suppose you are adding internationalization functionality to an existing product, so that messages display in the language of the user’s choice. You could change existing use cases to describe the multi-language display of messages, but you might prefer to write a few declarative functional requirements instead. Some clients insist on the traditional approach of specifying all requirements in declarative statements. You must develop the traditional SRS, but you can also make use cases for your developers. You may want to develop all use cases or only a few illustrative use cases to show central functionality and architectural significance. Non-functional requirements, such as performance requirements, are almost always specified with declarative statements. We’ll explore specifying non-functional requirements later in this module.


Specifying Software Requirements in Use Cases

Each use case Describes actions the system takes to deliver

something of value to the actor Shows the system functionality that an actor uses Models a dialogue between the system and actors Is a complete and meaningful flow of events, from the

perspective of a particular actor

Use-Case Model

Presenter

Presentation Notes

Use cases contain the detailed functional software requirements. Every time a use case says “The system responds by doing …”, that is a detailed requirement that the system must do. Also, remember the definition given previously: “A sequence of actions performed by a system which yields a measurable result of value for a particular actor.” A use case consists of a set of actions, decisions and stimuli that are transmitted to either the invoking actor or other actors. “Measurable result of value” -- important in determining the correct level for a use case (don’t get too small use cases). A use case shall make sure that an actor can perform a task that has an identifiable value. “A particular actor” -- helps us avoid use cases that are too large.


<Use-Case Name>*1. Brief Description*2. Flow of Events*

Basic Flow of EventsAlternative Flows of Events

3. Special Requirements4. Pre-Conditions5. Post-Conditions6. Extension Points7. Relationships*8. Use-Case Diagrams9. Other Diagrams/enclosures

Use-Case Report: Template

The Use-Case Report contains detailed information about an individual use case

TP5: Use Case Report Template

Presenter

Presentation Notes

We started out in the Use-Case-Model Survey showing overview properties of all use cases: Name, Brief description and Relationships. Now we specify each individual use case in more detail. The Use Case Report describes the details of a particular use case. The heart of the Use Case Report is the flow of events for the use case, which describes the behavior of the use case in a way that the customer understands. In the use case report, there are 9 sections, one for each type of property. We recommend that you use a standard template for your use-case reports, such as the one shown here (from the Rational Unified Process). Whether or not you have any properties within the section, stick to the standard outline. Some properties of a use case are required. The required properties are shown with an asterisk on the outline above. That is, a use case must have a name, brief description, flow of events, and at least one relationship. All other properties are optional. If there are no entries in the section for an optional property (for example, Special Requirements), the use-case report will have the section heading and a single entry to indicate there are “No entries in this section.” Each of the properties in the Use Case Report is discussed on the following slides.


Use-Case Properties in the Use-Case Report

Name (same as in Use-Case-Model Survey) Brief description (same as in Use-Case-Model Survey) Flow of events

The use case’s behavior What the actors do, what the system does in response

Special requirements Requirements about this use case not covered in flow of events Usually non-functional requirements

Pre-conditions Constraints on when the use case may start

Post-conditions Constraints on the system after the use case has ended

Presenter

Presentation Notes

Flow of events should represent what the use case does in the system, how and when it begins and ends, when the use case interacts with an actor, and what information is exchanged. We will discuss this in more detail in the following slides. Special requirements are requirements relating to this use case that are not covered by the flow of events but that could influence the design of the system. These are usually non-functional constraints for this use case, such as reliability and performance. Pre-conditions are constraints on when a use case can start. It is not the event that starts the use case. Rather, it is what must be true before the use case can begin. State the pre-conditions only if they are needed for clarification. Post-conditions are the states the system can be in after the use case has ended. State the pre-conditions only if they are needed for clarification.


Use-Case Properties in the Use-Case Report (cont.)

Extension points Places in the flow of events to attach extensions

Relationships (same as in Use-Case-Model Survey) Associations with actors and with other use cases

Use-Case diagrams Visual model of all relationships involving this use case

Other Diagrams or enclosures Interaction, activity, or other diagrams Pictures of the user interface

Presenter

Presentation Notes

Extension points are named places in the Flow of Events where extensions can be attached. We will discuss extensions and extension points in a later module. Relationships list all the associations that this use case has to actors and to other use cases, with brief descriptions where applicable. We have already studied the “communicates-association” between an actor and a use case. We will discuss relationships between a use case and another use case in a later module. Use-Case diagrams: You may choose to illustrate how a use case relates to actors and other use cases in a use-case diagram (in unusual cases more than one diagram) owned by the use case. A diagram is useful if the use case is involved with many actors, or has relationships to many other use cases. A diagram of this kind is of "local" character since it shows the use-case model from the perspective of one use case only. Other diagrams and enclosures can be included if they help to clarify the use case. For example, interaction or activity diagrams can be used if they help to clarify the flow of events. You may also choose to illustrate the flow events with pictures of the user interface (sketches or printouts from a prototype).


Sample Basic Flow of EventsWithdraw Cash Use Case

1. Insert Bank CardThis use case begins when the Bank Customer inserts a bank card in the card reader on the ATM machine. The ATM validates the card.

2. Enter PINThe ATM asks for the customer PIN code. The Bank Customer enters the PIN code.

3 Select ‘Withdraw Cash’The ATM displays the different alternatives that are available on this unit. The Bank Customer selects “Withdraw Cash”.

Presenter

Presentation Notes

Here is an example from the ATM System.


Sample Basic Flow of Events (cont.)4. Enter Account and Amount

The ATM asks for account to withdraw from and amount to withdraw. The Bank Customer enters account and amount.

5. Debit Bank AccountThe ATM sends the card id, PIN, amount and account to the Bank Consortium. The Bank Consortium replies that the transaction is accepted. The ATM system reports to the Bank Customer that it is ready to dispense cash.

6. Print ReceiptThe ATM asks the Bank Customer if a receipt is desired. The Bank Customer requests a receipt. The ATM system prints the receipt.

7. Receive Cash and CardThe ATM system dispenses money to the Bank Customer, and returns the Bank Card. The use case ends.

Presenter

Presentation Notes

The text is structured into sections. In this example, each section has a number and a name. The number makes it easier to refer to places in the text, especially useful when it comes time to review. The name allows you to quickly browse through the text and get an overview of what happens in the flow.


Sample Alternative Flows of Events

A1. Bank Card Not ValidIf in Step 1, Insert Bank Card, the card is not valid, it is ejected to the Bank Customer with a "sorry not a valid card" message. The use case ends.A2. Wrong PINIf in Step 5, Debit Bank Account , the Bank Consortium reply indicates a wrong PIN. The message "wrong PIN" is shown to the Bank Customer. The Bank Customer has three tries to get it right. If the Bank Customer correctly enters the PIN, the basic flow resumes at Step 4, Enter Account and Amount. Otherwise the card is kept by the ATM machine and the use case ends.

What other alternatives can you think of?

Presenter

Presentation Notes

Here is an example alternative flows from the ATM System.


Exercise: Choosing a Style for the Flow of Events

Read the different flow of events descriptions on the following three (3) slides and answer the following questions: Who is the intended audience?

Which is the easiest to understand (read)? Which do you think is the easiest to write? Is any one “better” than the others? Which one do you prefer? Why?

Presenter

Presentation Notes

One of the following flow of events comes from an early user of the Rational Unified Process. The others are changes from the first one to show different ways to write a flow of events. Look at the three types of flow of events and compare them. The way to describe the flow of events depends factors such as: Who is the reader? It may differ from project to project. Sometimes you may have a "customer" of the system, or other times you need to try to understand what the market wants without having a “customer”. Depending on who will be reading the flow of events, there are many different ways to write it. If the readers are unfamiliar with the system and the Rational Unified Process, you should describe it in one way. On the other hand, if the systems are well known to all readers, you may choose to describe it in another way. It is not easy to make everyone in a project team write the flow of events “in the same way”. The style depends on many factors, including the skills and background of the authors and the audience. For example, if some people have problems expressing themselves, it may be easier to make a more formal template for the flow of events.


Flow of Events - Style Type IOrderers can create Orders to collect measurement data from Network Elements.

The system will assign the Order a unique name and default values for when and how long the measurement should be and also how often it is to be repeated. These values can of course be edited by the Orderer.

The Orderer must further specify which measurement function, network element and measurement objects to apply. The Orderer can also add a personal comment to the order.

When necessary information is defined, a new Order is created and initialized with the defined attributes, the name of the creator, date of creation, and status of the order will be set to 'scheduled'. (Possible values for the status are: Scheduled, Executing, Completed, Canceled, and Erroneous).

The Operator is then notified that a new Order has been created and receives a reference to the new Order so that it can be displayed.

Presenter

Presentation Notes

Who is the intended audience? Is it easy to understand (read)? Do you think it would be easy to write? Is it “better” than the others? Which one do you prefer and why?


1. Request a Measurement OrderThis use case starts when the Operator requests a Measurement Order. The system displays all available Network Elements that the operator has the authority to access.

2. Configure Network Elements• The operator selects which network elements to measure, and chooses

measurement objects and functions for each selected network element. • The operator indicates he is finished configuring network elements.

3. Specify Measurements• The system give the measurement order a unique name and displays

default values for when, how often, and for how long the measurements should be made. The operator edits the default values as needed.

• The operator optionally enters a comment on the order.

4. Create Measurement OrderThe operator requests the system to create the measurement order. The system confirms creation of the measurement order with the operator and provides a reference to it. The use case ends.

Flow of Events - Style Type II

Presenter

Presentation Notes


Flow of Events - Style Type III=> 'Administrator order' (User identity)REPEAT

<='Show administrator order menu'IF (=> 'Creating an Order' (Measurement function,

network element, measurement object)) THENThe system finds a unique name, default values for when, how often and for how long the measurement should be executed.<= 'Show order' (Default attributes)REPEAT

=> 'Edit order' (Attribute to change, New value of attribute)<= 'Update screen' (New attributes)

UNTIL (All attributes are defined)REPEAT

IF (=> 'Edit order' (Attribute to change, New value of attribute)) THEN <= 'Update screen' (New attributes)ELSIF (=> 'Save order' (Order identity, Attributes)) THEN

The order is created and initialized in the system with the defined attributes, the name of the creator, date of creation and the status 'scheduled'.)

ENDIFUNTIL (=> 'Quit')

ENDIFUNTIL 'Quit administrator order'

Presenter

Presentation Notes

Who is the intended audience? Is it easy to understand (read)? Do you think it would be easy to write? Is it “better” than the others? Which one do you prefer and why?


Exercise: Perspectives in Flow of Events

Now, read the different flow of events descriptions on the following two (2) slides and answer the following questions: Who is the intended audience? Which is the easiest to understand (read)? Which do you think is the easiest to write? Is one “better” than the other? Which one do you prefer? Why?

Presenter

Presentation Notes


Outside Perspective

Flow of Events1. The use case starts when the subscriber

lifts the phone, and gets a dial tone. 2. The dial tone disappears when the

subscriber dials the first digit. 3. The subscriber dials the rest of the

number and will then hear a ring tone if the called party is not busy.

4. The ring tone will disappear if the called party answers the phone call.

5. The call continues until both parties hang up their phones.

6. If the called party is busy the subscriber will hear a busy tone and will then hang up the phone.

Local Call

Subscriber

Presenter

Presentation Notes

The flow of events can be described from different perspectives. The outside perspective focuses on the dialogue between the actor and the system, but it more or less neglects the inside of the system. Who is the intended audience? Is it easy to understand (read)? Do you think it would be easy to write? Is it “better” than the others? Which one do you prefer and why?


Inside PerspectiveFlow of Events

1. The use case is initiated when the subscriber lifts the phone and the system finds the correct subscriber object, marks it busy and gives a dial tone to the subscriber.

2. The system turns off the dial tone when the subscriber dials the first digit. The system loads the digit into a register and will then wait to receive and store the rest of the digits.

3. When the system has received enough digits it will start to analyze the received digits.

4. When the whole number has been analyzed the system will find the corresponding subscriber object and check whether or not it is marked busy.

5. If the called party is not busy the system will busy mark the object and start ...

Local CallSubscriber

Presenter

Presentation Notes

The inside perspective shows both the dialogue between actor and system and what the system does. Who is the intended audience? Is it easy to understand (read)? Do you think it would be easy to write? Is it “better” than the others? Which one do you prefer and why?


How to Refine a Use Case Flow of Events Gradually add detail to the step-by-step outlineWork together with users to refine the outline

• Include all events in the outline• Sketch outlines on large paper• Expect to revise the outline many times

First refine the Basic Flow of Events• What normally happens

Then refine the Alternative Flows

Presenter

Presentation Notes

In the “Find Actors and Use Cases” activity, we identified the use cases and sketched a step-by-step outline. The outline of the flow of events for a use case had two main sections: Basic Flow of Events and Alternative Flow of Events. The outline is used as a base when you start to write the full use-case specification. In the activity “Detail the Use Case”, we gradually add more detail to the flow of events. We want to understand what really happens so we don't miss anything. Typically, we begin with refining the Basic Flow and then we refine the Alternative flows. Flow of events can be 5-15 pages long, depending on complexity of the use case. Be sure that your description is complete and that you have answered all the questions that people may have about the events in the use case.


Questions To Help Detail The Flow of Events Sequence What event starts the use case? How does the use case end? How does the use case repeat some behavior? Are there optional situations in the use case?

Action What does each actor do? What does the system do?

Interaction How does the use case interact with actors? What data is exchanged with actors?

Presenter

Presentation Notes

Here is a list of questions to help you make decisions about the details in the flow of events.


What does NOT belong in the Flow of Events? Do NOT describeEvents outside the use case

• In other use cases• Between an actor and others outside the system

System operations not visible externallyDetails of the user interface

• Unless it is an important requirement

Avoid vague terminology Such as “for example”, “etc. ” and “information”

Presenter

Presentation Notes

You should not describe what happens outside the use case since that cannot be controlled. Describe only what happens in this use case so that if anything changes, you will only have to look inside this one use case to make the change. Try to describe what the system does only if it is externally observable. The externally observable events are the requirements -- the things the system is required to do to satisfy the user needs. In contrast, the things the system does that are not externally observable are really the responsibility of the system designers. If you include a description of the user interface that is too detailed, you will have to change the description each time you change the user interface. Try to keep this part in a prototype where it will be easy to change. Unclear expressions may hide important information. Do not wait to understand the system; bring every thing out in the light.


Guidelines For Refining the Basic Flow of Events Structure the basic flow into steps Give each step a number and/or a title Describe each step in 1-3 sentences Make each step a roundtrip of eventsWhat the Actor does:

• When the <Actor> requests <System> to ...What the System does in response:

• <System> sends message to <Actor> and ...

Presenter

Presentation Notes

There are many styles for writing flows of events. We recommend numbering and titling each step so that the reader can get the overview of the flow without having to read all the details, and can refer to a step when it is being reviewed. But there are many other styles. You can encourage consistency in style by specifying acceptable style guidelines when you write your Use-Case Modeling Guidelines. When you detail each step in the outline, be sure to describe the flow of events, not only what the system is doing. A suggestion for how to enforce this is to start every step with “When the [actor] ... ”. We recommend making each step in the flow of events show a roundtrip of events, usually in the form of messages: What the actor does: <Actor> messages <System> , and What the system does in response: <System> messages <An Actor> ... Making each step a roundtrip ensures testability, ensures adherence to the spirit of the purpose of a use case, and makes sequence diagrams far easier. Note that some interactions are system-controlled. That is, after the user’s initial request to begin the use case, the system controls the interaction: the system asks for information, and the user supplies information; the system asks for additional information and the user supplies it; etc. In these cases, a roundtrip within a step would begin with system actions, and then have the user response.


Exercise: Detail the Basic Flow of Events

Describe each step in the basic flow of events for one or more use cases in your project Start with the step-by-step outlines written for your use

case model (in Unit 5) Give each step a title Describe each step in more detail: add 1 to 3 sentences Focus only on the normal “happy day” path through the

use case. No alternative flows, yet! Write neatly so that you can copy and distribute the text

to the rest of the group

Presenter

Presentation Notes

Now that we have learned a little more about detailing a use case, let’s fill out our step-by-step outline with more detail. For this exercise, we will focus only on the basic flow of each use case -- the “happy day” scenario.


Why Divide a Flow of Events into Alternative Flows? Keep basic flow short and easy to read Isolate optional sequences

• Variant events• Optional events• Exceptions and errors

Isolate sequences executedseveral times in same flowClarify traceability

Presenter

Presentation Notes

Once we start filling in the details of the basic flow of events, adding structure may improve understanding of the text in the basic flow. We developed alternative flows in the outline we made in the Find Actors and Use Cases activity. Now that we’ve developed the basic flow, we may find other subflows to break out into Alternative Flows. We want the basic flow of events to be relatively short and very easy to read (like a single story line). We’ll put most of the other details in alternative flows. Each alternative flow is usually short and easy to read. But there are usually a lot of alternative flows, to cover all of the optional behavior. So, in most use cases, the alternative flows are the largest part of the flow of events.


How to Refine The Alternative Flows

Use one section for each alternative flow Give each alternative flow a number and title Divide into steps only if it helps clarify

Describe what happens in the alternative flow Where in the basic flow or another subflow the

alternative flow starts The condition for doing the alternative flow Behavior within the alternative flow Where basic flow or another subflow is resumed

Describe the order of the alternative flows Only describe order of flows as fixed, if it is In other cases, point out that the order is unfixed

Presenter

Presentation Notes

There are always different ways to structure the text. The main goal is, as usual, is to make the document easy to read. Describe the alternative flows in their own section, not within the basic flow (although some have found it useful to put pointers where these may be inserted for clarification purposes). The sequential nature of written text will imply to the reader that there is a sequence order to the behavior in the flow of events. To avoid misunderstandings, you should always point out whether the order of the alternative flows is actually fixed or not. Considerations of this kind are often related to: Business rules. For example, the user has to be authorized before the system can make certain data available. User-interface design. For example, the system should not enforce a certain sequence of behavior that may be intuitive to some but not to other users.


Specific Alternative Flows

Occur at a specific step in another flow Example

A3. Not Enough Money in AccountIf the Bank Consortium finds that there is not enough money in the Bank Customer’s bank account, the ATM sends the Bank Customer an error message "Sorry not enough money”. The Bank Customer has an opportunity to enter a new account and amount.

Presenter

Presentation Notes

Here is one way to write an Alternative Flow that only occurs at a specific place.


Specific Alternative Flows Should make clear references Where you pick up the sequence of actions Where you hand it over to another flow

Previous example, with clearer referencesA3. Not Enough Money in AccountIn Step 5, Debit the Account, of the basic flow, if the Bank Consortium replies to the ATM that there is not enough money in the Bank Customer’s bank account, the ATM sends the Bank Customer an error message "Sorry not enough money”. The ATM continues at Step 4, Enter Account and Amount, of the basic flow.

Presenter

Presentation Notes

This example is a more specific way to write the alternative. Another option is to specify a point within the basic flow where an alternative may occur, for example: 5. Debit Bank Account The ATM sends the card id, PIN, amount and account to the Bank Consortium. The Bank Consortium replies that the transaction is accepted. The ATM system reports to the Bank Customer that it is ready to dispense cash.[A3] 6. Print Receipt The ATM system asks … The important part is that you don’t want to pollute your basic flow with a lot of details (like you can’t see the forest for all the trees). Usually, you can let the Alternative Flow point into the Basic Flow instead of the other way around. Just think if you have 40 alternative flows -- that will create a lot of exemptions in the basic flow -- so many you might not be able to read it. There is no point in bringing the problem of code into a use case -- Remember that a use case is to be read by humans.


General Alternative Flows

Occur anywhere in another flow Example

A4: QuitThe ATM will allow the Bank Customer to quit at any time during the use case. The ATM will stop the transaction, log the transaction, and eject the Bank Card. The use case ends.

Presenter

Presentation Notes

Here is an example of an Alternative Flow that may occur anywhere


Another Example: Alternative Flows of EventsBasic Flow of Events1. Request a Measurement Order

This use case starts when the Operator requests a Measurement Order. …2. Configure Network Elements

The operator selects which network elements to measure, and chooses ... 3. Specify Measurements

The system give the measurement order a unique name and displays …3. Create Order

The operator requests the system to create the measurement order. ...

Alternative Flows of EventsA1. No Network Elements Available

If, in Step 1, no Network Elements are available to measure for this Operator, the system will inform the operator. The use case then ends.

A2. No Measurement Functions AvailableIf, in Step 2, no measurement functions are available for the selected network elements, the Operator may select other Network elements.

A3. Cancel Measurement OrderThe system will allow the Operator to cancel all actions at any point during the use case. The system will delete the Order and then end the use case.

Presenter

Presentation Notes

This example shows the structure of a complete flow of events. Notice the structure of this flow. By numbering the steps, you can reduce the number of words and make it more understandable.


Exercise: Detail the Alternative Flows Further detail at least three (3) alternative flows

for each use case in the previous exercise Continue the description of the flow of events of the use

cases in your class project Use the alternatives identified in the step-by-step

outlines written for your use cases (in Module 5) Describe clearly what will happen in each alternative Write neatly so that you can copy and distribute the text

to the rest of the group

Presenter

Presentation Notes

Now that we have learned a little more about detailing a use case, let’s fill out our step-by-step outline with more detail on the alternative flows. For this exercise, we will look at the basic flow of each use case -- the “happy day” scenario -- and consider, “What else could happen?” or “What could go wrong?”


Using pre- and post-conditions Pre- and post-conditions are observable to the user Use only if needed for clarification

A pre-condition Constraint on when use case can start NOT the event that starts the use case

A post-condition Guaranteed true when

use case ends Should apply regardless of

alternative flows May contain different variants

Pre- and Post-Conditions

Presenter

Presentation Notes

Pre-conditions and post-conditions should be observable to the user. A pre-condition for a use case is a constraint that must be true before the use case can begin. It is not the event starting the use case. For example, “The user has logged on to the system” or “The user has opened the document.” A post-condition for a use case should be true regardless of which alternative flows were executed; it should not be true for the main flow alone. If something should fail, you should use a post-condition like, “The transaction is completed or, if something failed, the transaction is not performed” rather than “The transaction is completed”.


Example of a Pre-Condition

Withdraw CashPre-condition The customer has a personally-issued card that fits in the

card reader, has been issued a PIN number, and is registered with the banking system.

Use only if needed for clarification!

Presenter

Presentation Notes

The states described by pre- or post-conditions should be stated in order that the user can observe. "The user has logged on to the system" or "The user has opened the document" are examples of observable states. A pre-condition is a constraint on when a use case can start. It is not the event that starts the use case. A pre-condition for a use case is not a pre-condition for only one subflow. You can also define pre- and post-conditions at the subflow level.


Example of a Post-Condition

Withdraw CashPost-condition At the end of the use case, all account and transaction

logs are balanced, communication with the banking system is reinitialized, and the customer has been returned his card or informed of where it will be sent.

Use only if needed for clarification!

Presenter

Presentation Notes

A post-condition for a use case should be true regardless of which alternative flows were executed; it should not be true only for the main flow. If something should fail, you would cover that in the post-condition by saying, "The action is completed or, if something failed, the action is not performed", rather than just, "The action is completed". Note: When you use post-conditions together with extend-relationships, you should take care that the extending use case will not introduce a subflow that violates the post-condition in the base use case. This will be discussed more in depth in the next module. Post-conditions can be a powerful tool for describing use cases. You must first define what the use case is supposed to achieve -- the post-condition. You can then describe the different ways to reach this condition (the flow of events needed).


What About Requirements NOT in Use Cases?

Use a declarative statement to describe the software requirement

Number and title each requirement Group related requirements for understandability Use language users can easily understand Use simple sentence structure: subject + active verb Consider using a keyword, for example “shall” Keep it short: state a requirement in 1 to 3 sentences Use terms from the glossary

Presenter

Presentation Notes

Use cases contain many of the detailed functional software requirements. But many other detailed software requirements are best stated in declarative sentences that are independent of use cases. In the following section,we’ll talk about specifying software requirements as declarative statements. Number and title each requirement so you can refer to it easily, especially when you are reviewing it. Requirements presented in a context are easier to understand. Grouping related requirements together provides some context. For example, all requirements about reliability may be grouped together. Both hierarchical relationships and packages can be used to group declarative statements of software requirements. Remember that the requirement specifications are for the users to read. Requirements have to be written for the user. Do not alienate them by using language they don't understand. Use simple sentences, with a straightforward sentence structure: subject followed by active verb object. Use terms from your glossary. The advantage of using a keyword, such as “shall” to identify each requirement is that it is immediately clear which statements are requirements and which are merely additional text. The disadvantage is that the use of a keyword in some requirements may make them stilted and difficult to understand.


Where Are Declarative Requirements Specified? Does requirement apply to a particular use case? Specify in the use case report In “Special Requirements” property

Does requirement apply to the whole system? Specify in the “Supplementary Specifications”

TP6: Supplementary Specifications Template

Presenter

Presentation Notes

If a non-functional requirement applies to a particular use case, then it is usually specified in the “Special Requirements” property of the use-case report for the particular use case to which it applies. For example, for the Withdraw Cash use case in an ATM system, there may be a non-functional requirement about the maximum allowable time for the system to respond to a request to withdraw cash. This performance requirement may be placed in the “Special Requirements” property of the Withdraw Cash use case. Supplementary Specifications contain the declarative requirements that are not about a particular use case. For example, in an ATM system, one of the non-functional requirements in the supplementary specifications may be a reliability requirement that the system must be operational 24 x 7 with no more than 10 minutes downtime per week.


Functional Requirements in Declarative Statements

Some functionality is easier to state declaratively Example: ATM System

1. InternationalizationThe ATM system shall display all messages and menus in the user’s preferred language.

Presenter

Presentation Notes

Some detailed functional software requirements are difficult to describe within the context of a use case. For example, internationalization requires that messages to the user are displayed in the user’s preferred language. In each step of each use case that displays a message, you could say to display the particular message in the language that the user prefers. Or, you can make a single declarative statement that applies to all displays in the entire system.


What about Non-Functional Requirements? The “URPS” of FURPS Usability Reliability Performance Supportability

Compliance with Legal and Regulatory requirements FCC FDA DOD ISO

Design Constraints Operating systems Environments Compatibility Application standards

What are some others?

Presenter

Presentation Notes

What other types of non-functional requirements need to be specified?


A Closer Look at the “URPS” of FURPS

Grady, 1992

Functionality Feature SetCapabilities

GeneralitySecurity

Usability Human FactorsAesthetics

ConsistencyDocumentation

Reliability Frequency/Severityof FailureRecoverability

PredictabilityAccuracyMTBF

Performance SpeedEfficiencyResource Usage

ThroughputResponse Time

Supportability TestabilityExtensibilityAdaptabilityMaintainabilityCompatibility

ConfigurabilityServiceabilityInstallabilityLocalizabilityRobustness

Presenter

Presentation Notes

We discussed FURPS at the beginning of the course. FURPS provides a checklist of items to make sure we are building a quality system. The FURPS acronym represent a portion of the types of requirements for which we should be searching; it reminds us to get non-functional (URPS) as well as functional (behavioral) requirements. Let’s look at the URPS categories in more depth. How can we specify URPS requirements?


Examples: Non-Functional Requirements

The ATM System The system can only handle one customer at a time. The system has to be available 24 hours a day, 7 days

a week, with less than .01% downtime.

What are some others?Where should each of these be specified?

Presenter

Presentation Notes

Two examples from the ATM machine.


Specifying Usability Requirements Definition of “usability” The ease with which software can be learned and

operated by the intended users Usability requirements Training time requirements, measurable task times User abilities (unsophisticated/sophisticated) Comparison to other systems that users know and like On-line help systems, tool tips, documentation needs Conformity with standards

• Examples: Windows, style guides, GUI Standards

Presenter

Presentation Notes

How can we “quantify” usability so it can be testable?


Davis Workshop, 1993

Specifying Reliability Requirements Definition of “reliability” The ability for the software to behave consistently in a

user-acceptable manner Reliability requirements Availability (xx.xx%) Accuracy Mean time between failures (xx hrs) Max. bugs per/KLOC (0-x) Bugs by class - critical, significant, minor

Reliability predictors Lines of code Complexity metrics

Presenter

Presentation Notes

How can we “quantify” reliability so it will be testable?



Specifying Performance Requirements Definition of “performance” A measure of speed or efficiency of the running system

Performance requirements Capacity Throughput Response time Memory Degradation modes Efficient use of scarce resources

• Processor, memory, disk, network bandwidth

Presenter

Presentation Notes

How can we “quantify” performance so it will be testable?



Specifying Supportability Requirements

Definition of “supportability” The ability of the software to be easily modified to

accommodate enhancements and repairs Supportability requirements Languages, DBMS, tools, etc. Programming standards Error handling and reporting standards

If not observable, state as intent or goals If not measurable or observable, it is not a requirement

Presenter

Presentation Notes

How can we “quantify” supportability so it will be testable? Here are some observable standards and tools that may be specified to enhance supportability. The supportability area is the hardest to specify as observable or measurable requirements. Often these items are stated as intent and goals.


Find what

Replace with

Replace

Start Cancel

How to Describe User Interfaces

Enclose sketches of proposed screen appearance with the use-case descriptions

Be careful not to specify too much of the design in the use-case documents

Presenter

Presentation Notes

The user-interface designer leads and coordinates the prototyping and design of the user interface, by: Capturing requirements on the user interface, including usability requirements Building user-interface prototypes Involving other stakeholders of the user interface, such as end-users, in usability reviews and use testing sessions Reviewing and providing the appropriate feedback on the final implementation of the user interface (as created by other developers, designers and implementers) A use-case storyboard is a logical and conceptual description of how a use case is provided by the user interface, including the interaction required between the actor(s) and the system. A boundary class models the interaction between one or more actors and the system.


How to Describe Communication Protocols

Specify a communication protocol if the actor is another system or external hardware The description of the use case should state if some

existing protocol is to be used If the protocol is new, it will be fully described during

object-model development

Presenter

Presentation Notes

You may need to define a communication protocol if the actor is another system or external hardware. The description of the use case should state if some existing protocol (http, tcp/ip) is to be used. If the protocol is new, you must fully describe it during the object-model development.


What About Design Constraints? A requirement allows more than 1 design option A design is a choice among options

A requirement that leaves no options is a design constraint Distinguish it from other requirements Place in a special section of your software requirements Identify the source of each Document the rationale for each

Examples An algorithm that is required to be used A database system that is required to be used

Presenter

Presentation Notes

Make sure that you can understand and make clear which requirements are constraints on the design.


WhatHow

WhatHow

WhatHow

Stakeholder Needs

Product or System Features

Software Requirements Specification (Use Cases)

Design SpecTest ProceduresDocumentation Plans

“One man’s ceiling

is another man’s floor”

Davis, 1993

The What vs. How DilemmaQuestion: How can you tell a requirement from design?

Answer: It depends on your point of view.

Presenter

Presentation Notes

A common question that frequently comes up when writing requirements is, “How can I write a requirement that tells the audience ‘what’ do to without specifying ‘how’ to do it?” Unfortunately, there is no one right answer. It depends on the intended point of view of the particular document reader. For example: When writing the Vision Document, the “what” are the user needs, and the “how” are the features For the SRS, the “what” are the features, and the “how” are the software requirements -- use case specification or supplementary requirements. For the others, … ?


Exercise: Non-Functional Requirements

For your class project, list at least 5 non-functional requirements

Decide where each non-functional requirement should be specified1. In the properties of a particular use case

• Special Requirements• Basic flow• Alternative flows

2. In the Supplementary Specifications

Presenter

Presentation Notes

Discuss what types of non-functional requirements might be attached to a use case? To the use-case model, that is the whole system?


ref - IEEE 1993

Qualities of a Software Requirement Specification

Correct Complete Consistent Unambiguous Ranked for importance and stability Verifiable Modifiable Traceable Understandable

Presenter

Presentation Notes

How will we be able to tell if we have a “good” Software Requirement Specification? IEEE has listed the following “qualities” of an SRS. We will discuss each of these qualities on this list and how they apply to our SRS on the following slides.


Qualities of an SRS: Correct

A Requirements Specification is “correct” if: Every requirement within it is something required of the

system to be built For example, every requirement in the SRS contributes

to the satisfaction of some need

Hint: Involve the people who have the problem or mission

ref - Davis ‘93

Presenter

Presentation Notes


IEEE 1993

Qualities of an SRS: Complete A Requirement Specification is “complete” if it

contains: All significant requirements Responses of the software to all inputs Full labels and references to figures, tables, diagrams Definitions of all terms and units of measure

(Glossary / Data Dictionary)

Presenter

Presentation Notes

Not only do all the requirements have to be correct, but the SRS needs to have a complete (leaving no holes) definition of the system. A Requirement Specification is “complete” if it contains: All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces Definitions of the responses of the software to all realizable classes of inputs, both valid and invalid, in all realizable classes of situations Full labels and references to all figures, tables, and diagrams Definitions of all terms and units of measure (Glossary / Data Dictionary)


A Requirements Specification is “consistent” if: Individual requirements described in it do not conflict

Hint: Trace all related requirements

IEEE 1993

SR101: The power LED shall be illuminated whenever the machine is on.

SR841: When the on-button is pressed, no observable results shall occur.

Qualities of an SRS: Consistent

SR245: When the on-button is pressed, the system shall illuminate the power LED.

(Inconsistent)(Consistent)

Presenter

Presentation Notes

Your SRS should not contain any inconsistent requirements. Sometimes this can be hard to determine in a complex system. Traceability can help.


ref - IEEE 1993

“A shall do B to C”



Req. 1

Qualities of an SRS: Unambiguous

A Requirements Specification is “unambiguous” if: Every requirement within it has only one interpretation

Presenter

Presentation Notes

Each stakeholder should have the same interpretation of what a particular requirement means.


Exercise: Exploring Ambiguity

Mary had a little lamb.In the space below, write (or draw) two interpretations of what this sentence means.

ref - Gause & Weinberg, 1989

Presenter

Presentation Notes

What comes to your mind when you read the above statement?


Exploring Ambiguity: Dictionary Definitionshad - past of havehave - 1a: to hold in possession as property

4a: to acquire or get possession of: OBTAIN (best to be had)c: ACCEPT; to have in marriage5a: to be marked or characterized by (have red hair)10a: to hold in a position of disadvantage or certain defeat b: TRICK, FOOL (been had by a partner)12: BEGET, BEAR (have a baby)13: to partake of (have dinner)14: BRIBE, SUBORN (can be had for a price)

lamb - 1a: a young sheep esp. less than one year old or without permanent teethb: the young of various other animals (as smaller antelopes)2a: a person as gentle or weak as a lambb: DEAR, PETc: a person easily cheated or deceived especially in trading securities3a: the flesh of lamb used as food

Presenter

Presentation Notes

We picked out two words from the sentence: “had” and “lamb” and looked them up in the dictionary. Here are some of the definitions listed. Now, what if we combined them? What does it do to the meaning of the sentence?


Exploring Ambiguity: Analysis have lamb Interpretation1a 1a Mary owned a little sheep under one year of age or

without permanent teeth.4a 1a Mary acquired a little sheep under one year of age or

without permanent teeth.5a 1a Mary is the person who owned a little sheep under

one year of age or without permanent teeth.10a 1a Mary held a little sheep under one year of age or

without permanent teeth in a position of disadvantage.10b 1a Mary tricked a little sheep under one year of age or

without permanent teeth.12 1b Mary gave birth to a young antelope.12 2a Mary is (or was) the mother of a particular small, gentle

person.13 3a Mary ate a little of the flesh of lamb.14 2c Mary bribed a small person trading in securities who

was easily cheated.

Presenter

Presentation Notes

By combining the different definitions of the words, we get very different meanings of this apparently simple statement.


Gause & Weinberg, 1989

What to Do About Language Ambiguity The Ambiguity Poll - create a measure that requires a

solid understanding of the problem to estimate. Memorization Heuristic - get various individuals to try to

recall the problem statement from memory. Parts that are not clear are likely the most ambiguous.

Key Word Technique - determine the key operational words in the statement and list their definitions. Mix and match to determine different interpretations. (Use these terms for glossary.)

Emphasis Technique - emphasize different words until as many interpretations as possible are discovered.

Other Techniques - use other techniques, pictures, graphics, formal methods -- that’s what use cases are for!

Presenter

Presentation Notes

Here are some of the methods listed by Gause and Weinberg for ways to identify ambiguity. An ambiguity poll is a poll of several people about a measure related to requirements, such as cost. If you ask several people to estimate the selected measure of a particular requirement. If they get wildly different answers then they probably have very different interpretations of the requirement. The memorization heuristic asks people to repeat the requirement from memory. If a person cannot remember part of a requirement, it is often because they did not understand that part, or that part was ambiguous. For example, can you quote the “Goal” stated at the beginning of the course? The emphasis technique brings out different possible interpretations by emphasizing different words in a sentence. For example, do you think of different meanings if I say “Mary HAD a little lamb?” and “Mary had a LITTLE lamb?”


Exploring Ambiguity: An ObservationTechniques that reduce ambiguity in an SRS often decrease understandability and alienate customers and users.

Our goal is to find the “sweet spot” where we attain the greatest understandability with the least ambiguity

Understandability

Ambiguity

The sweet spot

Presenter

Presentation Notes

Have you ever read a document that was “completely” unambiguous? Was it at all understandable? Our goal is to reduce ambiguity as much as possible, while still increasing understandability. Once we see that by reducing it further, it will also decrease understandability, then it’s time to back off. Try to find that apex “sweet spot” in the curve.


Use natural language for most of the specification Write as clearly and concisely as possible Use pictures, diagrams, and dialogs to further

illustrate the intent and features of the application

Augment with use cases and other formal techniques to fully define the functionality

Ambiguity vs. Understandability: What to Do?

Presenter

Presentation Notes

Always start with describing the requirement using natural language or text. Don’t immediately jump into structured or formal techniques unless it’s needed for understandability by the readers.


ref - IEEE 1993

Ranked by importance

SR103SR172SR192SR71SR63

SR172SR103SR63 SR71 SR192

Ranked by stability

Qualities of an SRS: Ability for Ranking A Requirements Specification is able to be

“ranked” for importance and stability if Each requirement in it has an identifier to indicate the

importance and stability of that particular requirement

Presenter

Presentation Notes

IEEE lists two attributes which they believe to be the most important in ranking requirements. It is often useful to be able to rank by any of the attributes (of course you will probably need a spreadsheet or other tool to do so!)


IEEE 1993

- The system supports up to 1,000 simultaneous users- The system shall respond to an arbitrary query in 500 msec.- The color shall be a pleasing shade of green- The system shall be user friendly- The system shall export view data in comma separated format

Qualities of an SRS: Verifiable A Requirements Specification is “verifiable” if: Every requirement in it is verifiable. [… to a degree that

convinces everybody!] There exists some finite, cost-effective process with

which a person or machine can check that the product meets the requirement

Are these requirements verifiable?If not, what is a better way to state them?

(Involve QA folks to help decide)

Presenter

Presentation Notes

Look at each of the above requirement statements and ask, “Is this testable?” Use your glossary to define key terms.


IEEE 1993

Qualities of an SRS: Modifiable

A Requirements Specification is “modifiable” if: Its structure and style are such that any changes to

requirements can be made easily, completely, and consistently, while retaining the structure and style. Features to facilitate modifiability

• Well organized• Table of contents• Index• Cross references• Minimum redundancy

Presenter

Presentation Notes

A SRS is more modifiable if it is well structured.


ref - IEEE 1993

Qualities of an SRS: Traceable A Requirements Specification is “traceable” if: The origin of each requirement is clear and each

requirement can be referenced in future development• Backward traceability (to previous stages of definition

or development)• Forward traceability (to all documents spawned by

the SRS) Hints: Make sure every requirement is referenceable

• Use unique numbers • Use labels• Use “shall" or other unique identifiers• Use a requirements repository to maintain traceability

Presenter

Presentation Notes

Can you think of any other tools that might help you with traceability?


Qualities of an SRS: Understandable

A Requirements Specification is “understandable”if: Both the user and supplier communities are able to fully

comprehend the requirements stated in it Hints: Early document should focus on general description

and features of the system Requirements writers must understand both audiences Use cases can help with understanding the system’s

functional requirements and boundaries

Presenter

Presentation Notes

Make sure that you write with your audience in mind and that you also meet the technicality level they would expect.


Adapted from Alan Davis

What Is Not in an SRS?

Design - How to accomplish the requirements Design Model specifies sub-components of a system

and/or their interfaces with other sub-components Verification - How you’ll know the requirements

have been met Test Model specifies test cases and test procedures

Project Data - When the requirements will be met Software Development Plan specifies schedules,

verification and validation plans, and configuration management plans

Presenter

Presentation Notes

The Design Model is an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code. The Design Model is used as essential input to activities in implementation and test. The Design Model could be included in the SRS for a very small system, but the SRS and the Design Model are usually separate documents because they have different authors and audiences. The Test Model is a collection of test cases and test procedures and their relationships. A test case can be implemented by one or more test procedures, and a test procedure may implement (the whole or parts of) one or more test cases. The Test Model and the SRS are usually separate documents because they have different authors and audiences. However, some customers, such as the U.S. Military, may require that the SRS include the Test Model. A Test Case is a set of test inputs, execution conditions, and expected results developed for particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. A Test Procedure is a set of detailed instructions for the set-up, execution, and evaluation of results for a given test case (or set of test cases). The Software Development Plan is a comprehensive, composite artifact, which gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and maintained throughout the project.


Review: Refine the System Definition

1. What is in a software requirement specification? 2. What are the properties of a use case?3. What is the purpose of the flow of events in a use case?

Who is it written for? What does the basic flow describe? What are some different types of alternative flows?

4. What are pre- and post-conditions? When should they be used?

5. What is the purpose of the “Special Requirements” of a use case?

(Continued )

Presenter

Presentation Notes


Review: Refining the System Definition6. What are some types of non-functional requirements?

Where should they each be specified?7. Is your industry bound by legal or regulatory

requirements? If so, what types of specifications should be written to assure

compliance?8. What is a design constraint? Where is it documented?9. What are some measures of a high quality software

requirement specification?10. What is not included in an SRS?

Presenter

Presentation Notes