What are Requirements? Functional requirements describe a list of functions that the system must accomplish. Nonfunctional requirements describe other.

What are Requirements?

• Functional requirements describe a list of functions that the system must accomplish.

• Nonfunctional requirements describe other constraints such as performance expectations or standards to be used.

• This discussion centers around functional requirements. Knowing what is to be built is one of the most important aspects of a software development process.

• Getting the requirements in line with what the actual users need is also a very important aspect.

Use Cases

• Requirements are often based on use cases. • A use case can be used to describe a systems functional

requirements.• A use case treats the system which is to be built as a

black box. A user (Actor) does something and the system responds.

• The use case is not described in terms of GUI components or specific systems. Instead it is described in more generic terms as simple user actions.

• For example, entering data, viewing the results of a query to the database, etc..

How can Requirements be Described?

• SRS– The IEEE and many government agencies

describe requirements through the use of Software Requirements Specifications (SRS). Each has a definition for the required contents.

• Use Cases– Requirements can be described as use

cases.

• The two traditionally haven’t been related.

Use Cases and RequirementsExample

• Actor:Auctioneer• UseCase:EnterBidInformation

– Requirement:InputPersonThe system shall allow the Auctioneer to enter the

contents of the city, name, useCreditCard associated with the Person

– Requirement:ProcessCreditCard The system shall allow the Auctioneer to run the

VerifyWithBank algorithm described as: Go out to the Bank server, process the credit card transaction

How can Requirements be Described? Cont’d

• Simulation– A mechanism which can be used to communicate the

requirements as use cases.– The simulation shows how the user interacts with the

system and how the system responds.

• Modeling– UML tools such as Together™ enable you to create

requirements by creating use cases. They provide diagrams to chose from which you can drag and drop.

RequireMentor™ Tool

• Guides you to describe use cases for a system which you are specifying– you pick and choose forms and fill in blanks

• Creates simulations of use cases• Relates requirements and use cases• Creates SRS• Creates a model

class diagrams sequence, activity, use cases

1. Define Actors

• Start by creating Actors and Job Titles

• Create separate types of Actors.

• They are distinguished by the Jobs that they do using the computer.

• Each Actor belongs to an organization

• Create all your known Actors and assign only the ‘Jobs’ for now. Job’s are optional.

Actors and Job Titles

• Attempting to answer the question:

• Who will be using the system and what types of activites do their jobs include?

2. Create Roles

• For each Actor, define one or more Roles.

• Roles are distinct interactions that an Actor has with the computer to accomplish a meaningful unit of work

• Later, you will define a Use Case for each role.

3.Create Use Cases

• Create Use Cases for each Actor, one for each of its Roles.

• For now, just fill out the Use Case name, select an Actor, and select one of its Roles.

4. Define a Story for each use case

• A Story is a sequence of screens which simulate how the Actor will interact with the system.

• A Story has an initial Screen.• Each Screen is associated with a

Requirement in the form:– The system shall …

• Choose from a fixed collection of Screen types

Five Screen Types

• Input Data

• View Data

• View and Select from Data

• Input from a Device

• Run Processing

5. Enter Info for the Screen Type

• Enter the Screen name

• Select a previously defined Data Entity (or define one on the fly

• Do not link Screen into a sequence by filling out Select Next screen at this time.

6. Define a Data Entity

• A Data Entity is named and has a collection of fields

• Each field has a type

• The type may be another Data Entity

Add Additional Screens

• Create another Screen for each of the Requirements within the Story

• The initial screen must be so designated

4. Link Screens Together

• Link a screen to another Screen defined for the story or to another story

• If you like to another Story, you can reuse it.

• For example, may want to always verify the user’s name and password from several different places.

• Link the Password Story as a next screen

6. View the Documentation

• As an Software Requirements Spec

• As a running simulation in html

• As an XMI(eye) file which can be imported into a UML tool

• Can also export the project as XML(el) or just save it

Together™ Import XMI

• Open Together 6.0

• Create a new Project using the Project Wizard

• Select File->Import->Model from XMI

• Class, Use Case, Sequence, and Activity Diagrams will be created

Guided Generation of Software Requirements

• RequireMentor™ was used to discover classes and methods

• Together™ was used to create the UML models

• RequireMentor™ provided guidance for– defining the contents of a use case– defining the format of requirements– generating many descriptions of the

requirements