1 cmpt 275 software engineering requirements gathering activity janice regan, 2008-2014

1

CMPT 275Software Engineering

Requirements Gathering Activity

Janice Regan, 2008-2014

Janice Regan, 2008-2014 2

Overview of Requirements Analysis

RequirementsSpecification

Analysis Model

RequirementsElicitation

Analysis

System Design

Functional requirementsFunctional model (scenarios)

Non-Functional requirements

Dynamic model

Static ModelAnalysis object model


Requirements Gathering/Specification

Client/User Software Developer

Project

Description

Informal Scenarios

And / or use casesQuestions

Requirements

Specification Document

Iterative process of successive evaluation and refinement. Remember the user/client will only be available for a ‘small’ number of iterations

Janice Regan, 2008-20144

Initial Requirements The initial specification of the requirements may

be created by the end users or by the technical staff or be based on interviews

Independent of the source of the initial specification of the requirements it must be refined and verified to be correct and complete What resources are available?

Are all users requests possible to implement with available resources? (scope is important)

Which requirements are most important? Less important? Even less important?

Understanding Client Needs The first step is to understand what the

system you will be building will do

A useful tool to help you understand this is the use of informal scenarios.

Based on information gathered from the client, tell stories of how the system will work from the clients point of view

From your point of view your are investigating WHAT the system will do


Example System To help us explain some basic concepts let

us consider a simple system

Student Registration System

Students may register in classes

Instructors may enter grades for classes

Instructors may view class lists

… What else?



Informal Scenarios Read Project Description or Requirements

provided by the client, or your notes about interviews with the client

Tell the story of one particular activity done by one particular user of the system

Purpose: Help conceptualization

Help understanding

Brings to light any ambiguity, misunderstood or problematic aspects of software system as described by the client/users


Roles Participants are people associated with

the project (software system) Client, developer, manager, end user

A set of related tasks that are assigned to a participant is a role A student (role) is assigned a group of related

tasks: registers in classes, receives grades

A teacher (role) is assigned a group of related tasks: gives classes, marks student work, gives grades


Actor Entity outside the software system

interacts with the system

Operates on objects in the system but cannot be operated upon by objects in the system.

Human, hardware device, another software system

Represents coherent role played by users e.g.: In an automated registration system

teacher, student, registrations data base


Actor A user of software system may take on

more than 1 role, usually at different times e.g.: Eva interacts with the system not only as

a student actor but also as a teacher actor

Eva teaches math, but is a student of French

An actor may represent more than one user e.g.: Both Eva and John may take the role of a

student


Primary and Secondary Actors Primary Actors

Actors who initiate a scenario (use case) causing the system to achieve a goal

automated registration system example the student or teacher is a primary actor

Secondary Actors Actors supporting the system so primary users

goals can be completed (do not initiate the use case or scenario)

automated registration system example the registration data base is a secondary actor


Primary and Secondary Actors It is possible for an Actor to be a primary

(initiating) actor in one scenario and a (non-initiating) or secondary actor in another scenario in the same system

For example in the automated registration system example When Eva registers in a French class she is the primary

actor (student) and the registration data base is the secondary actor.

Periodically the registration data base (primary actor) uses the registration data to print notifications of registration to be sent to students.


Informal Scenarios: Concrete Values Tell the story of one particular activity.

Use concrete values to make the activity particular rather than generic A concrete value gives a value for a specific

person or thing in the system

A student registered in a course (generic)

John Smith registered in MATH 232 (concrete)

Examples of possible scenarios Alan Smith, who is a student, will register

in CMPT 333

Jane Doe, an instructor, will obtain a copy of the class list for ENG 99

Kev Wu, an instructor, will enter the final grades for all students in MATH 222

Can you give some more examples?



Informal Scenario, first example

Describe Scenario:

Instructor Jane Doe wishes to obtain a copy of the class list for ENG 99

Current System State: Initial state waiting for input.

System moves into initial state after an instructor logs into the system

Jane Doe is an instructor for ENG 99


Informal Scenario, first exampleOutline of informal Scenario:

Jane selects “generate class list” from the list of possible tasks displayed on the screen in the initial state

Jane enters the name of the class she wishes to generate a class list for and requests the list

The system displays the class list Jane prints the class list Jane indicates she is done

Next Scenario:

System returns to the initial state. Any scenario that begins in the initial state may be the next scenario


Another Example System: Library management system (LMS)

This system is mean to keep track of present location of resources available in a library, (books and other items) and of all library users (patrons) and what they have presently borrowed from the library. It also records information about all library staff and all librarians


Example: Informal Scenarios What are a few potential informal

scenario’s for the LMS Library student patron John returns a book

“Training Your Dog” Library faculty patron Sue reports a book

“What I am missing” has been lost Librarian Bob receives a shipment of 5 new

books (“Birds v1” … “Birds v5”) and wishes to add them to the Library management system

Staff member Ellen requests a library card


Formulating Informal Scenarios Should be short

Should address one activity

Should specify concrete values

May address some form of user error

Implementation/GUI details should be omitted

System state prior to initiation should be described

The next scenario (ending state) should be indicated


Informal Scenario, check out

Describe Scenario:

Student patron John wishes to check out a book “Calculus Fun”

Current System State:

Initial state waiting for input.

System moves into initial state after Librarian logs into the system, or finishes an action

John is a valid student patron of the library


Informal Scenario, how to startOutline of informal Scenario:

Librarian enters John’s ID into the system The system tells the librarian about John The system says John can check out more

books the Librarian enters information for “Calculus Fun” into the system

The system adds “Calculus Fun” to the list of items John has borrowed

Next Scenario:

System returns to the initial state


Importance: Current System State The steps in the scenario outline, or the

outcome of the informal scenario may change depending on the initial state of the system

Example: Assume a student library patron may borrow up to 16 books, then the example scenario will change according to how many books the patron has already borrowed (see next slide)


Importance: Current System State Current System State: John has 10 books

checked out Informal Scenario as given on previous slide

Current System State: John has 16 books checked out John has reached his borrowing limit, John

cannot check out more books

A new scenario is needed to describe what happens


Alternate Informal ScenarioDescribe Scenario:

Student patron John wishes to check out a book “Calculus Fun”

Current System State:

Initial state waiting for input. System moves into initial state after Librarian

logs into the system John, a student patron of the library, has

already checked out 16 other books


Alternate Informal ScenarioOutline of informal Scenario:

Librarian enters John’s ID into the system The system tells the librarian about John The system says John has reached his

borrowing limit and cannot check out more books

The librarian tells John he cannot borrow more books

Next Scenario:



Specify Concrete Values Why is it important to specify

concrete values? To understand how the system will

respond to different types of situations, To better understand the application

domain, what values are important and how do they interact


Specify Concrete Values Concrete values for our new example (book titles

omitted for brevity)

John is a student library patron Each patron has an ID, John’s ID is ? John is trying to check out 9 books John already has 4 books on loan from the library One book John has on loan is overdue All books John wished to borrow are available for

loan. John has paid all previous library fines


Questions arising Applying the concrete values to the outline of the informal

scenario raises questions.

First need to know if John MAY check out all the books he has selected

How many books may a student check out at one time? What is the form of the ID used by the library? May a student patron check out more books if he has

overdue material on loan? May a student check out more books if he has

outstanding library fines? These are the types of questions that may need to be

clarified in your discussions with the client. You can find these questions by using informal scenarios as a tool


Refining Scenarios The answers to the questions arising from the

specific concrete values describing our student patron John will give us more information A student patron may borrow up to 16 books

Books cannot be borrowed if the patron has outstanding overdue charges

Books can be borrowed if the patron presently has overdue books

Books on reserve cannot be borrowed

We can then refine (add more detail, correct problems) our scenario


Informal ScenarioIdentify Scenario:

Student Patron John wishes to check out nine specific books (titles omitted for brevity). All these books are available to be checked out (none are on reserve)

Current System State: Library management system initialized and

waiting for input (initial state). Student patron John has 4 books on loan,

one of them is overdue. John owes no overdue charges


Informal ScenarioOutline of Informal Scenario:

Librarian enters John’s ID into the system (12 digit number)

The system tells the librarian that John has four books on loan, that one of those books is overdue, and that no library fines are outstanding.

The system tells the librarian how many more books John can check out. (maximum 16- 4, maximum 0 if old fines unpaid) John can check out up to 12 books.


Informal Scenario Outline of Informal Scenario

(continued):

The Librarian enters information for each book that John can to borrow into the system

Those books are added to the list of items John has borrowed

Next Scenario:



Importance of Next Scenario When all steps in the outline of the informal

scenario have been completed What can happen next?

What is the state of the system?

In what state does the completed scenario leave the system? The Final state of the system, after the present

scenario has been completed, becomes the current state of the system at the start of the next scenario

To know what the system can do next we need to know the state the system is in when the present scenario is completed

1 cmpt 275 software engineering requirements gathering activity janice regan, 2008-2014

Documents

gradesjanice regan

activityjanice regan

clientusersjanice regan

dojanice regan

actora user of software

importantwhich requirements

project software systemclient

rolea student role