LAB LAB

Agent and Object Technology Lab

Dipartimento di Ingegneria dell’Informazione

AOT

AOT LAB LAB

LAB LAB

Advanced Software Engineering Requirements Engineering

Requirements Engineering

Prof. Agostino Poggi

AOT

AOT LAB LAB

Š It may range from a high-level abstract statement of a service or of a system constraint to a detailed

mathematical functional specification

Š This is inevitable as requirements may serve a dual function

function

ƒ May be the basis for a bid for a contract: therefore must be open to interpretation

open to interpretation

ƒ May be the basis for the contract itself: therefore must be defined in detail

defined in detail

Š Both these statements may be called requirements

AOT

AOT LAB LAB

Š Requirements engineering is the process of establishing

ƒ The services that the customer requires from a system

ƒ The constraints under which it operates and is developed

Š Goal of the requirements engineering is to gather and analyze the descriptions of the system services and analyze the descriptions of the system services and constraints

AOT

AOT LAB LAB

Š Many people have difficulty understanding the

difference between scope, requirements and design

ƒ Scope demonstrates the needs of the organization, and is documented in a vision and scope document

ƒ Requirements document the behavior of the software that will satisfy those needs

ƒ Design shows how those requirements will be implemented technically

AOT

AOT LAB LAB

Š In principle, requirements should state what the

system should do and the design should describe how it does this

Š In practice, requirements and design are inseparable

ƒ A system architecture may be designed to structure the requirementsequ e e ts

ƒ The system may interoperate with other systems that

t d i i t

generate design requirements

ƒ The use of a specific design may be a domain requirementp g y q

AOT

AOT LAB LAB

Š Use case analysis

ƒ Mostly focused on writing text and the simple use of overview context diagrams is often enough

context diagrams is often enough

ƒ Use cases are just a part of functional requirementsUse cases are just a part of functional requirements

describing the interactions inside the system and between the system and its users and providers

Š Structural analysis – domain modeling

ƒ Finding the “real-world” objects involved in the use cases and creating class diagrams to represent them

creating class diagrams to represent them

AOT

AOT LAB LAB

Š Behavioral analysis

ƒ Creating activity diagrams and sequence diagrams to capture use case details

ƒ Activity diagrams for business workflow

ƒ Sequence diagrams for reactive behavior (also with timing)

ƒ Possibly creating state charts to capture external reactive behavior of the system and other domain objects

AOT

AOT LAB LAB

Š System customers

ƒ Help in their specification and read them to check whether th ti f th i d

they satisfy their needs

ƒ Help in specifying of changes in the requirements

ƒ Help in specifying of changes in the requirements

Š ManagersM

U th t l bid f th li ti f th t

ƒ Use them to plan a bid for the realization of the system

ƒ Use them to plan the system development process

ƒ Use them to plan the system development process

AOT

AOT LAB LAB

Š System engineers

ƒ Use them to understand what system must be developed

Š System test engineers

ƒ Use them to develop the validation tests for the system

Š System maintenance engineers

ƒ Use them to understand the system and the relationships between its parts

between its parts

AOT

AOT LAB LAB

Š On the basis of the type of the system feature

ƒ Functional requirements

ƒ Non-functional requirements

ƒ Domain requirements

Š On the basis of their static / dynamic nature

Š On the basis of their static / dynamic nature

ƒ Enduring requirements

V l til i t

ƒ Volatile requirements

Š On the basis of their audience

ƒ User requirements

ƒ System requirementsy q

AOT

AOT LAB LAB

Š Capture the intended behavior of the system

ƒ This behavior may be expressed as services, tasks or functions the system is required to perform

Š Describe how the system should react to particular

inputs and how the system should behave in particular inputs and how the system should behave in particular situations

ƒ Describe functionality or system services

AOT

AOT LAB LAB

Š Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Š Specify criteria that can be used to judge the operation of a system, rather than specific behaviors

Š Constrains the design and the implementation of the system, but does not describe a service that the

system should provide

AOT

AOT LAB LAB

Š Product requirements

ƒ Requirements which specify that the delivered product must behave in a particular way

• E.g. execution speed, reliability, etc.

Š Organizational requirements

ƒ Requirements which are a consequence of organizational policies and procedures

• E.g. process standards used, implementation requirements, etc.

Š External requirements

ƒ Requirements which arise from factors which are external to the system and its development process

E i t bilit i t l i l ti i t t

• E.g. interoperability requirements, legislative requirements, etc.

AOT

AOT LAB LAB

Non-functional requirements

Product Organisationalg External

requirements

requirements requirements

Efficiency Reliability requirements

Portability Interoperability Ethical requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requirements

requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements

AOT

AOT LAB LAB

Š Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify

Š Goal

ƒ A general intention of the user such as “ease of use”

ƒ A general intention of the user such as ease of use

Š Verifiable non-functional requirement

ƒ A statement using some measure that can be objectively tested

Š Goals are helpful to developers as they convey the intentions of the system usersy

AOT

AOT LAB LAB

Š A goal

ƒ The system should be easy to use by experienced controllers

d h ld b i d i h th t

and should be organized in such a way that user errors are minimized

Š A verifiable non-functional requirement

ƒ Experienced controllers shall be able to use all the system functions after a total of two hours training After this training functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day

AOT

AOT LAB LAB

Š Speed: processed transaction per second, user event response time, screen refresh time

Š Size: Kbytes, number of RAM chips y , p

Š Ease to use: training time, number of help frames

Š Reliability: mean time to failure probability of

Š Reliability: mean time to failure, probability of unavailability

R b t ti t t t ft f il t f

Š Robustness: time to restart after failure, percentage of events causing failure, probability of data corruption on f il

failure

Š Portability: percentage of target dependent statement, number of target systems

AOT

AOT LAB LAB

Š Requirements that come from the application domain of the system and that reflect characteristics of that domain

Š Can be either functional or non-functional thatCan be either functional or non functional that

constraints existing requirements or define specific computations

computations

ƒ If domain requirements are not satisfied the system may be

ƒ If domain requirements are not satisfied, the system may be unworkable

AOT

AOT LAB LAB

Š Stable requirements derived from the core activity of the customer organization

Š For example a hospital will always have doctors

Š For example, a hospital will always have doctors, nurses, etc.

Š They may be derived from domain models

AOT

AOT LAB LAB

Š Requirements which change during development or when the system is in use

Š For example in a hospital requirements derived fromFor example, in a hospital, requirements derived from health-care policy

Th b di id d i t bl t

Š They can be divided in mutable, emergent, consequential and compatibility requirements

AOT

AOT LAB LAB

Š Mutable requirements

ƒ Requirements that change because of changes to the environment in which the organization is operatingg p g

ƒ For example, in hospital systems, the funding of patient care may change and thus require different treatment information may change and thus require different treatment information to be collected

Š Emergent requirements

ƒ Requirements that emerge as the customer's understandingRequirements that emerge as the customer s understanding of the system develops during the system development

ƒ The design process may reveal new emergent requirements

ƒ The design process may reveal new emergent requirements

AOT

AOT LAB LAB

Š Consequential requirements

ƒ Requirements that result from the introduction of the computer system

ƒ Introducing the computer system may change the

organizations processes and open up new ways of working which generate new system requirements

Š Compatibility requirements

Š Compatibility requirements

ƒ Requirements that depend on the particular systems or business processes within an organization

business processes within an organization

ƒ As these change, the compatibility requirements on the

commissioned or delivered system may also have to evolve commissioned or delivered system may also have to evolve

AOT

AOT LAB LAB

Š Description of the system services and its operational constraints that is understandable by system users who don’t have technical knowledge

Š Written mainly for customers

ƒ Client managersg

ƒ System end-users

ƒ Client engineeringC e t e g ee g

ƒ Contractor manager

ƒ System architectsSystem architects

Š User requirements are defined using natural language, tables and diagrams

tables and diagrams

AOT

AOT LAB LAB

Š More detailed specifications of user requirements

Š Written for both client and contractor

ƒ System end users

ƒ System end-users

ƒ Client engineering

S t hit t

ƒ System architects

ƒ Software developers

Š Can act as a contract between client and contractor

Š System requirements may be expressed using system

Š System requirements may be expressed using system models

AOT

AOT LAB LAB

Š Is a document that clearly specifies the system

requirements as identified during the requirements process

Š Should include both a definition and a specification of requirements

requirements

Š Should describe what the system should do rather than how it should do it (It is not a design document)

how it should do it (It is not a design document)

Š This document is called:

ƒ System Specification if it deals with hardware and software

ƒ Software Requirements Specification (SRS) if it deals only q p ( ) y with software

AOT

AOT LAB LAB

Š There are standards such as IEEE 830 which dictate the requirements for an SRS conforming to that

standard

Š A standard template for software requirements

specifications may be used within organizations to aid specifications may be used within organizations to aid in the production of consistent and complete

requirements documents requirements documents

ƒ SRS standards or templates may help to provide structure and consistencyy

ƒ SRS standards or templates may also impede the effective specification of requirements

AOT

AOT LAB LAB

Š Introduction

Š General description

Š Purpose

Š Scope

Š General description

Š Specific requirements

Š Scope

Š Definitions, acronyms, and abbreviations

and abbreviations

Š References

Š Overview

Š Functional

requirementsq Š Overview

Š External interface requirementsq

Š Performance

requirements Š Product perspective and functions

U h t i ti

Š Design constraints

Š Attributes

Š User characteristics

Š General constraints

Š Other requirements Š Assumptions and dependencies

AOT

AOT LAB LAB

Š Use a layered format that provides increasing detail as the layers deepen

Š Use consistent graphical notation and apply textual

Š Use consistent graphical notation and apply textual terms consistently

Š Be sure to define all acronyms

Š Be sure to include a table of contents and if possible

Š Be sure to include a table of contents and, if possible, an index and/or glossary

Š Write in a simple, unambiguous style

Š Always put yourself in the reader’s position

Š Always put yourself in the reader s position

AOT

AOT LAB LAB

Š Problems arise when requirements are not precisely stated

Š Ambiguous requirements may be interpreted in different ways by developers and users

Š Consider the term appropriate viewers:

ƒ User intention: special purpose viewer for each different document type

document type

ƒ Developer interpretation: provide a text viewer that shows the

t t f th d t

contents of the document

AOT

AOT LAB LAB

Š In principle requirements should be both complete and consistent

ƒ Complete: they should include descriptions of all facilities required

ƒ Consistent: there should be no conflicts or contradictions in the descriptions of the system facilities

the descriptions of the system facilities

I ti it i diffi lt i ibl t d

Š In practice, it is very difficult or impossible to produce a complete and consistent requirements document

AOT

AOT LAB LAB

Š Understandability

S i t b d i th l f th

ƒ Some requirements may be expressed in the language of the application domain

• This is often not understood by software engineers developing the

• This is often not understood by software engineers developing the system

ƒ Some requirements may be expressed in the language of q y p g g developers

• This is often not understood by customers of the system

Š Implicitness

ƒ Domain specialists understand the area so well that they do not think of making the domain requirements explicit

ƒ Development specialists may consider that some technical solutions implicitly follows the requirements

AOT

AOT LAB LAB

Š Conflicts between different non-functional requirements are common in complex systems

Š Consider some requirements of a spacecraft system:

T i i i i ht th b f t hi i th

ƒ To minimize weight, the number of separate chips in the system should be minimized

ƒ To minimize power consumption, lower power chips should be used

ƒ However, using low power chips may mean that more chips have to be used

have to be used

AOT

AOT LAB LAB

Š Lack of clarity

ƒ Precision is difficult without making the document difficult to read

Š Requirements confusionq

ƒ Functional and non-functional requirements tend to be mixed-upq p

Š Requirements amalgamation

Š Requirements amalgamation

ƒ Several different requirements may be expressed together

ƒ Several different requirements may be expressed together

AOT

AOT LAB LAB

Š Ambiguity

ƒ The readers and writers of the requirement must interpret the same words in the same way, but natural language is naturally ambiguous so this is very difficult

Š Over flexibility

Š Over-flexibility

ƒ The same thing may be said in a number of different ways in the ifi ti

specification

Š Lack of modularization

Š Lack of modularization

ƒ Natural language structures are inadequate to structure system requirements

requirements

AOT

AOT LAB LAB

Š Invent a standard format and use it for all requirements

Š Use language in a consistent way:

ƒ Same syntax for the description of the requirements

ƒ Same terms for the same type of requirements

Š Use text highlighting to identify key parts of the requirementq

Š Avoid the use of computer jargon p j g

AOT

AOT LAB LAB

Š Behaviors/Constraints:

ƒ Shall: system has to do it 100% of the time unless specifically excepted

ƒ Should: desirable that system does it whenever reasonable to do so

ƒ Can: system can do something, but no particular incentive to implement

Š User Actions:

ƒ Must: user has to do this (same as “shall” except for user

ƒ Must: user has to do this (same as shall , except for user, not computer)

ƒ May: user can exhibit this behavior but does not have toMay: user can exhibit this behavior, but does not have to

AOT

AOT LAB LAB

Š Environment:

ƒ Will: designer can count on environment being this way

ƒ Might: designer has to accommodate situation, but can’t count on it

Š Change risk:g

ƒ Expected to: this area is likely to changed

ƒ Could: this area is something that could change, but might not

AOT

AOT LAB LAB

Š The processes used for requirements engineering vary widely depending on:

ƒ The application domain

ƒ The people involved

ƒ The organization developing the requirements

Š However, there are a number of generic activities common to all processes:p

ƒ Requirements elicitation

ƒ Requirements analysisRequirements analysis

ƒ Requirements validation

ƒ Requirements managementRequirements management

AOT

AOT LAB LAB

Requirements

Requirements q

Elicitation and Analysis Feasibility

Study

Specification

Requirements Validation Feasibility

Report

System Models p

User and System Requirementsq

Requirements Document Document

AOT

AOT LAB LAB

Requirements

System requirements specification and modeling

q

Specification

User requirements specification

Business requirements specification

System requirements

elicitation

User requirements specification

Feasibility study User requirements

elicitation Prototyping

Requirements Requirements

Elicitation

Reviews

System requirements

Requirements Validation

y q

document

AOT

AOT LAB LAB

Š User involvement

Š Clear statement of requirements

Š Proper planning

Š Realistic expectations

S ll j t il t

Š Smaller project milestones

Š Clear vision and objectives

Š Clear vision and objectives

Š Hard working and focused staffg

AOT

AOT LAB LAB

Š A feasibility study decides whether or not the proposed system is worthwhile

Š A short focused study that checks

ƒ If the system contributes to organisational objectives

ƒ If the system can be engineered using current technology and within budget

ƒ If the system can be integrated with other systems that are used

used

AOT

AOT LAB LAB

Š Based on information assessment (what is required), information collection and report writing

Š Questions for people in the organisation

Š Questions for people in the organisation

ƒ What if the system wasn’t implemented?

ƒ What are current process problems?

Ho ill the proposed s stem help?

ƒ How will the proposed system help?

ƒ What will be the integration problems?

ƒ Is new technology needed? What skills?

Wh t f iliti t b t d b th d t ?

ƒ What facilities must be supported by the proposed system?

AOT

AOT LAB LAB

Š Identify relevant sources of requirements (usually customer)

Š Determine what information is needed

Š Determine what information is needed

Š Analyze the gathered information looking forAnalyze the gathered information, looking for

implications, inconsistencies, or unresolved issues

Š Confirm your understanding of the requirements with the source

Š Synthesize appropriate statements of the requirements

AOT

AOT LAB LAB

Š The customer fully explore and fully understand their requirements

Š The customers are able to separate their wants fromThe customers are able to separate their wants from their needs

Š The c stomers are able to nderstand the capabilities

Š The customers are able to understand the capabilities and limitations of computer technology

Š The customers understand the alternative solutions and impact of each alternative

Š The customers understand the impact of the requirements on the developer and themselves requirements on the developer and themselves

AOT

AOT LAB LAB

Š The developers are solving the right problem

Š Th d l h fid th t th t t b

Š The developers have confidence that the system to be delivered is feasible to build

Š The developers have the trust and confidence of the

Š The developers have the trust and confidence of the customer

Š The developers gain domain knowledge of the systemp g g y

AOT

AOT LAB LAB

Š The customer probably will be dissatisfied

Š The customer and developer have to cope with constantly changing requirements

Š The developer is solving the wrong problem

Š The developer has a difficult time building the systemp g y

AOT

AOT LAB LAB

Š SamplingSampling

ƒ Process of collecting a representative sample of documents, forms, and records

Š Observation of the work environment

ƒ A fact-finding technique where the systems analyst either

ti i t i t h i t l b t th t

participates in or watches a person in to learn about the system

Š Questionnaire

A i l d t th t ll th l t t ll t

ƒ A special-purpose document that allows the analyst to collect information and opinions from respondents

Š Interviews

Š Interviews

ƒ A fact-finding technique whereby the systems analysts collect information from individuals through face-to-face interaction g

AOT

AOT LAB LAB

Š Organization chart

Š Memos and other documents that describe the problem

problem

Š Documentation and standard operating procedures for p g p current system

Š Manual and computerized screens and reports

Š Samples of databases

Š Samples of databases

Š Etc.

AOT

AOT LAB LAB

Š Randomization

ƒ A sampling technique characterized by having no

d t i d tt l f l ti l d t

predetermined pattern or plan for selecting sample data

Š Stratification

ƒ A systematic sampling technique that attempts to reduce the variance of the estimates by spreading out the sampling

ƒ For example, choosing documents or records by formula and by avoiding very high or low estimates

by avoiding very high or low estimates

AOT

AOT LAB LAB

Š Determine the who, what, where, when, why, and how of the observation

Š Obtain permission from appropriate supervisors or managers

managers

I f th h ill b b d f th f

Š Inform those who will be observed of the purpose of the observation

Š Keep a low profilep p

AOT

AOT LAB LAB

Š Take notes during or immediately following the observation

Š Review observation notes with appropriate individuals

Š Don't interrupt the individuals at work

Š Don't focus heavily on trivial activitiesy

Š Don't make assumptions

Š Don t make assumptions

AOT

AOT LAB LAB

Š Data gathered can be very reliable

Š Can see exactly what is being done in complex tasks

Š Relatively inexpensive compared with other techniques

Š Relatively inexpensive compared with other techniques

Š Can do work measurements

AOT

AOT LAB LAB

Š People may perform differently when being observed

Š Work observed may not be representative of normal di i

conditions

Š Ti i b i i t

Š Timing can be inconvenient

Š Interruptions

Š Interruptions

Š Some tasks not always performed in the same way

Š Some tasks not always performed in the same way

Š May observe wrong way of doing thingsMay observe wrong way of doing things

AOT

AOT LAB LAB

Š Free-format questionnaire

ƒ A questionnaire designed to offer the respondent greater l tit d i th

latitude in the answer

ƒ A question is asked and the respondent records the answer

ƒ A question is asked, and the respondent records the answer in the space provided after the question

Š Fixed-format questionnaire

ƒ A questionnaire containing questions that require selecting an answer from predefined available responses

an answer from predefined available responses

AOT

AOT LAB LAB

Š Determine what facts and opinions must be collected and from whom you should get them

Š Don't get carried away

Š Don t get carried away

Š Based on the facts and opinions sought, determine

whether free- or fixed-format questions will produce the best answers

Š Write the questions

T t th ti ll l f d t

Š Test the questions on a small sample of respondents

Š Duplicate and distribute the questionnairep q

AOT

AOT LAB LAB

Š Unstructured interview

ƒ An interview that is conducted with only a general goal or subject in mind and with few if any specific goal or subject in mind and with few, if any, specific questions

ƒ The interviewer counts on the interviewee to provide a framework and direct the conversation

Š Structured interview

ƒ An interview in which the interviewer has a specific set of questions to ask of the interviewee

set of questions to ask of the interviewee

AOT

AOT LAB LAB

Š Open-ended question

ƒ A question that allows the interviewee to respond in

h i

any way that seems appropriate

Š Closed-ended question

ƒ A question that restricts answers to either specific choices or short, direct responses

Š Often the open-ended and closed-ended are mixedp

AOT

AOT LAB LAB

Š Select interviewees

ƒ Learn about individual prior to the interview

Š Prepare for the interview

ƒ Interview guide is a checklist of questions

Š Conduct the interview

ƒ Establish rapport

ƒ Summarize the problem

ƒ Offer an incentive for participation / ask the interviewee for assistance

F ll th i t i

Š Follow up on the interview

ƒ Memo that summarizes the interview

ƒ Thank you!

ƒ Thank you!

AOT

AOT LAB LAB

Š Types of questions to avoid

ƒ Loaded questions

ƒ Leading questions g q

ƒ Biased questions

Š Interview question guidelines

Š Interview question guidelines

ƒ Use clear and concise language

ƒ Don’t include your opinion as part of the question

ƒ Avoid long or complex questions

ƒ Avoid threatening questions

ƒ Don’t use “you” when you mean a group of peopley y g p p p

AOT

AOT LAB LAB

Do's Don‘ts

Š Be courteous

Š Listen carefully

Š Continue an interview unnecessarily

y

Š Maintain control P b

Š Assume an answer is

finished or leading nowhere

Š Probe

Š Observe mannerisms and

Š Reveal verbal and non verbal clues

nonverbal communication

Š Be patient

Š Using jargon

Š Reveal your personal biases p

Š Keep interviewee at ease

Š Maintain self control

Š Talk instead of listen

Š Assume anything about the

Š Maintain self-control topic and the interviewee

AOT

AOT LAB LAB

Š Find, verify, clarify facts

ƒ About what stakeholders do

ƒ About how stakeholders might interact with the system

Š Generate enthusiasm

Š Get the end-user involved

Š Solicit ideas and opinions

AOT

AOT LAB LAB

Š Interviews are not good for understanding domain requirements

ƒ Requirements engineers cannot understand specific

ƒ Requirements engineers cannot understand specific domain terminology

ƒ Some domain knowledge is so familiar that people g p p find it hard to articulate or think that it isn’t worth articulatingg

AOT

AOT LAB LAB

Š Refines and structures the requirements to facilitate understanding (by developers), reuse, maintenance, etc.

Š Yields a more precise and formal specification of requirements and defines the analysis model

ƒ Refine the informal description of the requirements

ƒ Convert the informal descriptions to flow diagrams

AOT

AOT LAB LAB

Š Stakeholders don’t know what they really want

Š Stakeholders express requirements in their own terms

Š Different stakeholders may have conflicting requirements

Š Organizational and political factors may influence the system requirements

system requirements

Š The requirements may change during the analysisq y g g y

ƒ New stakeholders may emerge and the business environment change

environment change

AOT

AOT LAB LAB

Requirements Requirements

Validation

Definition and Specification

Domain

Understanding Prioritization

Understanding

C fli t Requirements

Collection

Conflict Resolution

Requirements Classification

AOT

AOT LAB LAB

Š The analysis model makes abstractions

ƒ It is not a design model

ƒ It is a platform (language, OS, …) independent model

Š A structured analysis model is based on the functions to be realized by the system

to be realized by the system

Š An object-oriented analysis model is based on the use

Š An object-oriented analysis model is based on the use cases and on the representation of the real objects and concepts of the system domain

concepts of the system domain

AOT

AOT LAB LAB Object-Oriented Analysis Model

class diagrams

state diagrams

sequence diagrams use case

diagrams

dynamic object

functional dynamic

model object

model functional

model

analysis analysis model

AOT

AOT LAB LAB

Š An analysis model is represented by an analysis system that is the top-level package of the model

Š An analysis system may contain subsystems orAn analysis system may contain subsystems or analysis packages

Š Within the anal sis model se cases are reali ed b

Š Within the analysis model, use cases are realized by analysis classes and interaction diagrams

Š Analysis classes represent an abstraction of classes (and possibly entire subsystems) of the system to be implemented

Š interaction diagrams describe dynamics of the system

Š interaction diagrams describe dynamics of the system

AOT

AOT LAB LAB

Š Use cases, stated simply, allow description of

sequences of events that, taken together, lead to a system doing something useful

Š A use case is simply a description (a story) of users and systems interacting in a typical fashion to go

and systems interacting in a typical fashion to go through the various paths or parts of a business process or automated process

process or automated process

Š Use cases describe the interaction between a primary p y actor, the initiator of the interaction, and the system itself, through a sequence of simple steps, g q p p

AOT

AOT LAB LAB

Š Use cases should describe all possible interactions within and with the system

Š Use cases are not mapped one-to-one to requirementspp q

ƒ Each requirement must be covered by at least one use case

ƒ However, use cases may contain many requirementsHowever, use cases may contain many requirements

Š Use cases are described by combining:

ƒ Use case diagrams

ƒ Use case diagrams

ƒ Textual descriptions

ƒ Interaction diagrams (optional)

ƒ Interaction diagrams (optional)

Š Use cases are realized by identifying the actors and

th i t ti b t th t d th t

the interaction between the actors and the system

AOT

AOT LAB LAB

Š Define system boundary to identify actors correctly

Š Identify users and systems that depend on the system’s primary and secondary functionalities sys e s p a y a d seco da y u c o a es

Š Identify hardware and software platforms with which the system interacts

the system interacts

Š Select entities that play distinctly different roles in the t

system

Š Identify as actors external entities with common goals and direct interaction with the system

Š Denote actors as nounsDenote actors as nouns

AOT

AOT LAB LAB

Š Business / Domain Use Cases

ƒ Interactions between users and the business (or domain)

Š S t U C

Š System Use Cases

ƒ Interactions between users and the system

ƒ One business use cases contains a set of system use cases

Š To name the use cases give it a verb name to show

Š To name the use cases, give it a verb name to show the action that must be performed

ƒ Describe a transaction completely

ƒ No description of user interface whatsoever

AOT

AOT LAB LAB

Š Tasks to be performed by the user and the systemp y y

Š Starting situation and states where it finishes

Š Flow of information to the user and to the system

Š Events that are conveyed to the user and to the system

N l fl f t

Š Normal flow of events

Š What can go wrongWhat can go wrong

Š Other concurrent activities

AOT

AOT LAB LAB

Š Is described by few steps (up to 5), but most important provides a meaningful result to the end users

Š Describes interactions and mechanisms not policies

Š Describes interactions and mechanisms not policies

Š Excludes user or system interfaces implementation choices

Š Is described by few (5 10) pages

Š Is described by few (5 - 10) pages

Š Has a single initiator actorg

Š Includes the major business exceptions and their handling

handling

AOT

AOT LAB LAB

Š Use cases can be ordered on the basis of their importance for the realization of the system

Š Ordering depends on:g p

ƒ Significant impact on the architectural design

ƒ Include risk, time-critical or complex function, p

ƒ Involve significant research and/or new and risky technology

ƒ Represent primary line-of-business processesRepresent primary line of business processes

ƒ Etc.

Š Ranking is usually expressed with qualitative values:

Š Ranking is usually expressed with qualitative values:

ƒ E.g., high, medium, low

ƒ E g must have essential nice to have

ƒ E.g., must have, essential, nice to have

AOT

AOT LAB LAB

Š Define the start state and the preconditions

Š Define when the use case starts

Š Define the order of activity in the main flow of eventsDefine the order of activity in the main flow of events

Š Define any alternative flows of events

D fi ti l fl f t

Š Define any exceptional flows of events

Š Define any post conditions and the end state

Š Mention the actors involved with this use case, and any use cases used or extended by this use casey

Š Mention the related interaction diagrams

Š Mention any design issues as an appendix

Š Mention any design issues as an appendix

AOT

AOT LAB LAB Use Case Template

Use Case ID:

Use Case Name:

Use Case Name:

Created By: Last Updated By:

Date Created: Date Last Updated:

Actors:

Description:

Trigger:

Preconditions:

Postconditions:

Normal Flow:

Alternative Flows:

i Exceptions:

Includes:

Priority:

Frequency of Use:

Business Rules:

S i l R i t

Special Requirements:

Assumptions:

Notes and Issues:

AOT

AOT LAB LAB Use Case Template

AOT

AOT LAB LAB

Š Try to describe use cases without thinking about in what way they will be implemented

Š Be as narrative as possible

Š State success scenarios

Š Introduce all the possible scenarios of a use cases

Š Agree on a “format style” for use case description

AOT

AOT LAB LAB

Š Name a use case starting with a verb in order to emphasize that it is a process

ƒ E.g., Buy Items, Enter an order, Reduce inventory, etc.

Š Document exception handling or branching

ƒ E.g., when a “buy item” fails, then …

E g hen a “credit card appro al ” fails then

ƒ E.g., when a “credit card approval ” fails, then …

Š Do not represent individual steps as use cases

Š Do not represent individual steps as use cases

ƒ E.g., define a use case for the operation: printing a receipt

AOT

AOT LAB LAB

Š Tutors in the organization are assigned courses to

teach according to the area that they specialize in and their availability

Š The organization publishes and maintains a calendar of the different courses and the assigns tutors every of the different courses and the assigns tutors every year

Š There is a group of course administrators in the

organization who manage the courses including course g g g content, assigning courses to tutors, and defining the course schedule

AOT

AOT LAB LAB

Š Courses shall be assigned to the tutors only by course administrators

Š Courses information topics and contents shall be managed only by course administrators

Š Tutors information shall be managed only by course administrators and by corresponding tutor

Š Course calendar shall be visualized by course administrators, tutors, and students

AOT

AOT LAB LAB

Š Courses and topics that make up courses

Š Tutors that teach courses

Š Course administrators who manage the assignment of courses to tutors

Š Calendars (course schedules) that are generated as a result of the work performed by the course

result of the work performed by the course administrators

Š Students who refer to calendars (course schedules) to decide which courses they wish to take up for studyy p y

AOT

AOT LAB LAB

Š Actors

ƒ Tutor, student, course administrator

Š Use Cases

Š Use Cases

ƒ Manage courses: view courses manage course topics and

ƒ Manage courses: view courses, manage course topics and manage course information

ƒ Manage tutors: view course calendar, view tutors, manage tutor information, and assign courses to tutors, g

AOT

AOT LAB LAB

CMS

Manage Course Contents

View Course

Student Manage Course

Information

View Course Calendar

Course

Administrator Manage Tutor

Information

Tutor View Tutors

Manage Course Topics

Assign Course to Tutor

AOT

AOT LAB LAB

Š Playlist Support

ƒ Download prebuilt playlist, create playlist, add songs to

playlist, reorder playlist, delete song from playlist, calculate

p y , p y , g p y ,

cost, check song availability

P t S t

Š Payment Support

ƒ Display payment options, payment by cash, payment by cell p y p y p p y y p y y phone, payment by credit card

Š Playback Mechanism

Š Playback Mechanism

ƒ Load song, play song, display song information

AOT

AOT LAB LAB

Š Payment by cash

ƒ Monitor cash input

ƒ Return proper changeReturn proper change

ƒ Refund money

Š Payment by cell phone

ƒ Display phone number to dialDisplay phone number to dial

Š Load Song

ƒ Fetch song from local database

ƒ Fetch song from network g

AOT

AOT LAB LAB

Jukebox

Create playlist Customer

Create playlist

Playlist

Song List Database

AOT

AOT LAB LAB

Property Description Use Case

Title Create Playlist

Goal Allow the customer to create a playlist

Scope Playlist Support

Level Primary Task

Precondition(s) Access to a song list database must be available Postcondition(s) Playlist has been created

Primary Actor 1 Song List Database Primary Actor 2 Playlist

Primary Actor 3 Customer Secondary Actor None

Trigger Event Customer Chooses to Create a Playlist

Step 1 Customer browses through song list database Exception 1.1p Timeout (Customer waited to long) ( g)

Step 2 Customer selects songs to add to play list Add Songs to Playlist Step 3 List of songs in playlist is displayed

Variation 3 1 Customer chooses to reorder playlist Reorder Playlist Variation 3.1 Customer chooses to reorder playlist Reorder Playlist

AOT

AOT LAB LAB

J k b Jukebox

Delete song from playlist

C l li

Customer

p y

«include»

Create playlist

Playlist Customer

i l d

«include»

Add song to

Reorder playlist

«include»

Song List Database

g playlist

AOT

AOT LAB LAB

Š Analysis classes are an abstraction of one or more real classes or subsystems of the to system to be realized

Š Analysis classes handle functional requirements

Š Analysis classes handle functional requirements

ƒ Non-functional requirements are handled in architectural design

Š Analysis classes are usually represented with class

Š Analysis classes are usually represented with class diagrams through the Boundary, Control and Entity stereotypes

stereotypes

ƒ The semantics of these stereotypes provides a consistent

th d f fi di d l i h l

method of finding and analyzing such classes

AOT

AOT LAB LAB

Š Provides a crisp abstraction of something from the problem domain (or solution) domain

Š Embodies a small well defined set of responsibilities and carry them out welly

Š Provides clear separation of abstraction specification

Š Provides clear separation of abstraction, specification, and implementation

Š Is understandable and simple yet extendable and adaptable

adaptable

AOT

AOT LAB LAB

Š Noun verb analysis

Š Use case drivenUse case driven

C l tt

Š Common class patterns

Š CRC cards

Š Mixed approach

AOT

AOT LAB LAB

Š Set of heuristics for identifying classes, attributes and associations from a requirements specification

ƒ Nouns may identify: classes attributes and instances

ƒ Nouns may identify: classes, attributes and instances

ƒ Verb phrases may identify: operations, relationships and constraints

Š Relies on the completeness and correctness of the f requirements document

Š Quality depends on style of writing, often there are too many nouns

AOT

AOT LAB LAB

Text Component Model Component Example

proper noun instance Jim Smith

common noun class toy, doll

doing verb method buy, recommend

classifying verb inheritance is a

classifying verb inheritance is a

possessive verb aggregation has a

modal verb constraint must be

adjective attribute 3 years old

transitive verb method enter

intransitive verb method (event) depends on intransitive verb method (event) depends on

AOT

AOT LAB LAB

Š Similar to the noon verb analysis, but centered on use cases

Š Identifies objects, responsibilities of each object, and j , p j , how these objects collaborate with other objects

analyzing the different scenarios described in the use y g cases

Š Relies on the completeness of use case models

Š Relies on the completeness of use case models

AOT

AOT LAB LAB

Š Derives classes from the generic classification theory of objects

ƒ Part of science that concerned with partitioning the world of objects into useful groups

Š Provide useful guidance, but not offering a systematic process to find complete and reliable classes

Š Too loosely bound to specific user requirements and possible misinterpretation of class name

possible misinterpretation of class name