use-cases elicitation and fast copyright, 2003 © jerzy r. nawrocki [email protected] ...

Use-Cases Elicitation and FAST Use-Cases Elicitation and FAST

Copyright, 2003 © Jerzy R. Nawrocki

[email protected]

www.cs.put.poznan.pl/jnawrocki/require/

Requirements EngineeringRequirements Engineering

Lecture Lecture 44

Requirements EngineeringRequirements Engineering

Lecture Lecture 44

J. Nawrocki, Use-Cases Elicitation ..

BibliographyBibliographyBibliographyBibliography

IEEE Guide for Information Technology – System Definition - Concept of Operations (ConOps) Document, IEEE Std 1362-1998, March 1998.

S. Adolph, P. Bramble, A. Cockburn, A. Pols, Patterns for Effective Use Cases, Addison-Wesley, Boston, 2003.


ContentsContentsContentsContents

Use Cases Elicitation PatternsUse Cases Elicitation Patterns

FAST Technique

Inception Steps


The TeamThe TeamThe TeamThe Team

• Small Writing TeamSmall Writing Team: Restrict the number of people refining any one work product to just two or three people.

• Participating AudienceParticipating Audience: Actively involve your customer and internal stakeholders in the use case development process when possible.

• Balanced TeamBalanced Team: Staff the team with people from different specialties. Make sure the team contains both developers and end users.


The Process - 1The Process - 1The Process - 1The Process - 1

• Breadth Before DepthBreadth Before Depth: Conserve your energy by developing an overview of your use cases first, then progressively add detail.

• Spiral DevelopmentSpiral Development: Develop use cases in an iterative, breadth-first manner, with each iteration prograssively increasing the precision and accuracy.

• Multiple FormsMultiple Forms: Select the format based on the risks associated with the project and the preferences of the people involved.


Short FormatShort FormatShort FormatShort Format

ActorActor

Administrator

Use CaseUse Case

Set Monitor Parameters

Select Monitor

DescriptionDescription

Person monitoring and controlling job control

system

DescriptionDescription

Allow administrator to specify boundaries and

Precision of items being monitored

Choose something to monitor (e.g. a process

or wait queue)


Fully Dressed FormatFully Dressed FormatFully Dressed FormatFully Dressed Format

Buy SomethingPrimary ActorPrimary Actor: RequestorGoal in ContextGoal in Context: Requestor buys something through the system, gets it. Does not include paying for it.ScopeScope: Business – The overall purchasing mechanism, electronic adn non-electronic, as seen by the people in the company.LevelLevel: SummaryStakeholders and InterestsStakeholders and InterestsRequestorRequestor: Wants what he/she ordered.CompanyCompany: Wants to control spending but allow needed purchases.VendorVendor: Wants to get paid for any goods delivered.PreconditionPrecondition: None



Success GuaranteesSuccess Guarantees: Requestor has goods, correct budet ready do be debited.

TriggerTrigger: Requestor decides to buy something.Main Success ScenarioMain Success Scenario1.1. RequestorRequestor: Initiate a request.2.2. ApproverApprover: Check money in the budget, check price of goods,

complete request for submission.3.3. BuyerBuyer: Check contents of storage, find best vendor for goods.4.4. AuthorizerAuthorizer: Validate Approver’s signature.. . .ExtensionsExtensions1a. Requestor does not know vendor or price: leave those parts blank

and continue.



PriorityPriority: VariousResponse TimeResponse Time: VariousFrequencyFrequency: Three times a dayChannel to Primary ActorChannel to Primary Actor: Internet browser, mail system, or equivalentChannels to Secondary ActorsChannels to Secondary Actors: Fax, phone, carOpen IssuesOpen Issues:When is a canceled request deleted from the system?What authorization is needed to cancel a request?


The Process - 2The Process - 2The Process - 2The Process - 2

• Two Tier ReviewTwo Tier Review: Hold two types of review: The first by a smaller, internal team, possibly repeated many times; the second by the complete group, perhaps just once.

• Quitting TimeQuitting Time: Stop developing use cases once they are complete and satisfactorily meet audience needs.

• Writers LincenseWriters Lincense: Small diffrences in writing style are inevitable.



Use Cases Elicitation Patterns

FAST TechniqueFAST Technique

Inception Steps


Developers Custom

ers

FASTFASTFASTFAST

FAST = Facilitated Application Specification Technique

JAD Joint Application Development - another approach to FASTFac

ilita

tor Recorder


FASTFASTFASTFAST

Facilitator - runs the meeting(s)

Recorder - takes notes, serves tape recorder or video recorder

Developers & customer representatives - work on requirements

Senior manager - knows about the meeting date & time

Persons involved


FASTFASTFASTFAST

The list of stakeholders should be ready before the project leaders start to organise the first FAST meeting.

Get from the customer the initial list of requirements sources (manuals, organisation charts, technical data, ..) and read it before the meeting.

Conducting a FAST meeting via phone or e-mail should be avoided.

Before the first meeting


FASTFASTFASTFAST

Product request ( Project Proposal)

Aim & goals of the meeting

Agenda for the meeting

Information about place and time

Input documents


FASTFASTFASTFAST

A worksheet to fill in

Missing stakeholders

Missing features and use cases

Use cases description

Input documents


FASTFASTFASTFAST

Product justification (consensus)

Presentation of the worksheets (one by one, no critique)

Deciding (discussion) about:• Stakeholders• Their goals • Features and use cases (at different levels)• Value and cost (priority)

An agenda example



Use Cases Elicitation Patterns

FAST Technique

Inception StepsInception Steps


Inception – Step 1Inception – Step 1Inception – Step 1Inception – Step 1

7-8.10.2004

Discuss:

• Project MandateProject Mandate

• Project Management Team

• Vision of the Product

• Project web page address


Software Development Studio Instytut Informatyki, Politechnika Poznańska, Piotrowo 3a, 60-965 Poznań, [email protected]

e-SDS: Internet-Based System Supporting the Software Development Studio

Project Mandate

Status: Ready for 2nd review File name: 1mandate-2.doc Author: Jerzy Nawrocki Modified on: 2003-10-06 00:29

About previous version: Status: Ready for 1st review File name: 1mandate-1.doc Author: Jerzy Nawrocki Modified on: 2003-10-01

Scope of changes: Customer Representative

Customer

Instytut Informatyki, Politechnika Poznańska ul. Piotrowo 3a, 60-965 Poznań tel.: 0-61 8790 790 fax: 0-61 877 15 25 http://www.cs.put.poznan.pl

Customer Representative

Jerzy Nawrocki [email protected] tel.: 0-61 665 24 49 fax: 0-61 877 15 25 http://www.cs.put.poznan.pl/jnawrocki

Short Product Description

e-SDS is to be an internet-base system that will support project management for the Software Development Studio. The system should focus on fostering communication between potential SDS customers, students, SDS staff, and project supervisors. The information about project should be available through internet. (using a web browser).

Constraints

The system should be ready by June 1st, 2004.

Customer Declaration

The customer declares: To arrange facilities for project meetings (including tea or coffee). To send a representative to project meetings but not more frequently than once a week.

***** END OF DOCUMENT *****



7-8.10.2004

Discuss:

• Project Mandate

• Project Management TeamProject Management Team

• Vision of the Product



SDS Project OrganisationSDS Project OrganisationSDS Project OrganisationSDS Project Organisation

Project Board

Project Assurance 5th year students

Project Support3rd year student

Analyst4th year student

Senior User

Customer

Executive Customer

Senior Supplier MJ | BW

Project Supervisor

Project Manager4th year student

Team3rd year students




Project Management Team

Status: Ready for 2nd review File name: 2manag-team-2.doc Author: Jerzy Nawrocki Modified on: 2003-10-06 01:13

About previous version: Status: Ready for 1st review File name: 2manag-team-1.doc Author: Jerzy Nawrocki Modified on: 2003-10-01

Scope of changes: Customer Representative

Executive

Jerzy Nawrocki [email protected] tel.: 0-61 665 24 49 fax: 0-61 877 15 25 http://www.cs.put.poznan.pl/jnawrocki

Senior User

Bartosz Walter [email protected] tel.: - fax: 0-61 877 15 25 http://www.man.poznan.pl/wally

Senior Supplier (Project Area Manager)

Michał Jasiński [email protected] tel.: 0-61 665 00 00 fax: 0-61 877 15 25 http://www.cs.put.poznan.pl/awojciechowski

Supervisor

Executive

Project Assurance and Project Management Auditor

Tomasz Sawicki [email protected] tel.: - fax: -


Project Assurance and Requirements Maturity Assessor

Radosław Krzywania [email protected] tel.: - fax: -

Analyst

Krzysztof Pospiech [email protected] tel.: - fax: -

Project Manager

Piotr Pawałowski [email protected] tel.: - fax: -




7-8.10.2004

Discuss:

• Project Mandate

• Project Management Team

• Vision of the ProductVision of the Product





Product Vision

Status: Ready for 2nd review File name: 3vision-2.doc Author: Jerzy Nawrocki Modified on: 2003-10-06 01:13

About previous version: Status: Ready for 1st review File name: 3vision-1.doc Author: Jerzy Nawrocki Modified on: 2003-10-01

Scope of changes: The impact of the problem Glossary

The Problem

Lack of information about the status of the SDS projects.

Affected People and/or Institutions

Potential SDS customers, students, supervisors, SDS staff.

The impact of the problem

Impression of chaos. Dissatisfaction of all the people involved in the SDS. ISO 9001 certification is impossible

Proposed solution

To build an information management system that would collect and present the information concerning the SDS projects. The system should use internet technology and user interface should be based on standard web browsers (e.g. MS Internet Explorer).

Assumptions and Constraints

The system should be ready by July 1, 2004.

Organizational Structure of the Users Environment

The users of the proposed system will be stakeholders of the SDS projects. The overall organization of the SDS is depicted in Fig. V1, and structure of each SDS project is presented in Fig. V2.


SDS Supervisor

Area Manager 1 Area Manager 2

_ Project 1 _ Project 7






Fig. V1. Organization of the SDS

Profile of User Classes

SDS Supervisor: Responsible for the SDS. Jerzy Nawrocki, [email protected].

Area Manager: Responsible for a group of projects. Michał Jasiński, [email protected] or Bartosz Walter, [email protected].

SDS Project Supervisor: A staff member responsible for a given project on behalf of the university.

Features

SubmitProjectProposal: Allows a prospective SDS customer to submit a project proposal. Value: High. Cost: Low

RegisterSupervisor: Allows a project supervisor to register as an SDS project supervisor. Value: High. Cost: Low.

Glossary

SDS: Software Development Studio at the Poznan University of Technology.

ISO 9001: An international standard concerning a quality management system.




14-15.10.2004Review:• Project Management Team• Vision of the ProductCheck if the project web page is ready (Mandate +

PMT + Vision)Discuss:• Operational Scenarios, Version1 (Use Cases)• Glossary, Version 1



21-22.10.2004Review:• Operational Scenarios, Version1 (Use Cases)• Glossary, Version 1Discuss:• Operational Scenarios, Version 2 (Use Cases)• Glossary, Version 2• Project Approach (outline of the Software

Development Plan)• Project Initiation Plan• Risk Factors



28-29.10.2004Review:• Project Brief (PMT + Vision + Operational

Scenarios + Glossary + Risk factors)• Project Approach (outline of the Software

Development Plan)• Project Initiation PlanSeek approval of the Project Initiation Plan


Studio Rozwoju Oprogramowania Instytut Informatyki, Politechnika Poznańska, Piotrowo 3a, 60-965 Poznań, [email protected]

e-SDS: System internetowy wspierający Studio Rozwoju Oprogramowania

Zatwierdzenie rozpoczęcia

Status: Wersja gotowa Nazwa pliku: 6ini-approval.doc Autor: Jerzy Nawrocki Ostatnia modyfikacja: 2003-10-06 04:47

Po zapoznaniu się z Opisem przedsięwzięcia (Project Brief) Sposobem podejścia do realizacji (Project Approach) Planem rozpoczęcia przedsięwzięcia (Project Initiation Plan)

stwierdzamy, że dokumenty te zostały przygotowane z należytą starannością i stanowią dobry punkt wyjścia do rozpoczęcia przedsięwzięcia. Niniejszym wyrażamy zgodę na rozpoczęcie przedsięwzięcia zgodnie z przedstawionym planem.

Funkcja Imię i nazwisko Data Podpis

Dyrektor przedsięwzięcia Jerzy Nawrocki

Reprezentant użytkowników Bartosz Walter

Reprezentant dostawcy Michał Jasiński

Promotor Jerzy Nawrocki

***** KONIEC DOKUMENTU *****


SummarySummarySummarySummary

Use cases elicitation practices:• Small Writing Team• Breadth Before Depth• Spiral Development• Multiple Forms• Two Tier Review• Quitting TimeFASTInception phase details


Quality assessmentQuality assessmentQuality assessmentQuality assessment

1. What is your general impression? (1 - 6)

2. Was it too slow or too fast?

3. What important did you learn during the lecture?

4. What to improve and how?

use-cases elicitation and fast copyright, 2003 © jerzy r. nawrocki [email protected] ...

Documents