Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.

Requirements Elicitation

3

Requirements Elicitation

• Requirement: a feature or constraint that the system must satisfy

• Requirements Elicitation: specification of the system that the clients can understand– Focus on describing the purpose of the system– Errors in the elicitation phase are expensive to fix

• Requirements Analysis: analysis model that the developers can understand

4

Requirements Elicitation

• Developers observe users in their environment and interview them

• They use Scenarios and Use cases, easy to understand by clients

• They also use prototypes for validation

• They produce Requirements Specification, it will be used as a contract

5

Part of requirements

• System functionality• Interaction between users and system• Environmental conditions

• Errors the system can detect and handle

6

Functional requirements

• Describes the interaction between the system and users

• The user could be anyone or anything that interacts with our future system

• Remember, nothing is left over, every aspect should be well defined.

• We are defining what the system should do, not how the system will do it.

• Both, the actor and system behaviour should be well defined

7

Non-functional requirements

• Describes the system overall attributes– Usability– Reliability– Performance– Supportability and maintainability

– Implementation requirements– Interface requirements-legacy system– Operational requirements-administration– Legal requirements-licensing

8

Requirements ElicitationActivities

1. Identify Actors2. Identify Scenarios3. Identify Use cases4. Identify Relationships between actors and use cases5. Identify initial analysis objects (conceptual class diagram)6. Identify non-functional requirements

9

Requirements Elicitation activitiesIdentifying Actors

• They are external to the system• Anyone or anything that interacts with our system• We can ask the following questions:

– Which user groups are supported by the system to perform their work?

– Which user groups execute system main functions?– Which user groups perform secondary functions?– With what external hardware or software will the system

interact?

10

Identify Scenarios and Use Cases

• High level piece of functionality that the system will provide• Scenarios are instances of use cases. Real events, real actors.• We can ask the following questions:

– What are the tasks that the actor wants the system to perform?

– What information does the actor access? Who creates that data? Can it be modified and removed? by whom?

– Which external changes does the actor need to inform the system?

– Which events does the system need to inform the actor?

FRIEND System Case Study

12

Refine Use cases

• The focus of this activity is on completeness and correctness– Elements manipulated by the system are detailed– Low-level sequence of interaction are specified– Alternative scenarios

• Many use case are rewritten many times• Others are refined• Others are dropped• U may use GUI mokups

13

Identify relationships among actors and use cases

• Actors and use cases–Initiate–Participate

• Between Use case:–Include–Extend

14

• How do we represent the include relationship?

• In the base use case– If the included use case can be invoked at any

point of the flow of event, we indicate the inclusion in the quality requirements

– If it is invoked during an event, we specify which event in the flow of event

• How do we represent the extend relationship?– In the extending use case’s entry requirement

15

Use case writing guidelines

• Use cases should be named with verb phrases• Actors should be named with noun phrases• The boundary of the system should be clear• The casual relationships between successive steps should be

clear• A use case should be a complete user transaction• Exceptions should be described separately • Do not get into technical stuff, such as design• Should not exceed 2-3 pages.

Identify initial analysis objects

• Use cases are main source

• Look for noun and noun phrases to identify entities

• Look for verbs and verb phrases to identify relationships between entities

17

Use Case Example

Use Case Name: Check Campaign BudgetBrief Intro: Checks whether the budget for a campaign is likely to be exceeded by the total cost of all the adverts that make it up.Actors: Campaign Manager Main Flow:1. The campaign manager enters the client name.[Exception: Known campaign name]2. The system lists all campaigns for that client (include Use Case: Find Campaign)3. The campaign manager selects the relevant campaign4. The system calculates the total cost of all adverts in the campaign,deducts this from the campaign budget and displays the balance. (Extension Points: Print Campaign Summary, Print Campaign Invoice)Alternative Flow: Known campaign name -The campaign manager knows the campaign name and entersit directly. The use case continues from step 4.

18

Use Case (with nouns identified)Use Case Name: Check Campaign BudgetSummary: Checks whether the budget for a campaign is likely to be exceeded by the total cost of all the adverts that make it up.Actors: Campaign Manager Description:1. The campaign manager enters the client name.2. The system lists all campaigns for that client (Include Use Case: Find Campaign)3. The campaign manager selects the relevant campaign4. The system calculates the total cost of all adverts in the campaign,deducts this from the campaign budget and displays the balance. Alternative Flow: Known campaign name -The campaign manager knows the campaign name and entersit directly. The use case continues from step 4.

Underline nouns and noun-phrases to identify possible objects

19

Candidate Classes (1)

Probable Possible Unlikely Pretty sure these are objects which will become classes;

What may be objects but we need to investigate further;

Look irrelevant, Describing whole

domain; Plural versions of

probables/possibles;

Duplicates which appear to be redundant;

What look like attributes;

Categorise on basis of confidence, but don’t lose objects

20

Candidate Classes (2)

Probable Possible UnlikelyCampaign,Advert,Client,CampaignInvoice,

Total Cost,CampaignManager,List of Staff,CampaignSummary,Budget,

System,Client name,Relevantcampaign,Balance,Campaign name,Adverts,Campaigns,

21

Candidate Classes (3)

Probable Possible Unlikely Campaign, Advert, Client, Campaign Invoice,

Total Cost, Campaign Manager, List of Staff, Campaign Summary, Budget,

System, Client name, Relevant campaign, Balance, Campaign name, Adverts, Campaigns,

Candidates may move from one list to another as knowledge gained

22

Candidate Classes (4)

Advert

cost

Cam paigncam paign nam ebudgetbalance

Cam paignInvoice

Client

client nam e

Candidate classes and attributes begin the Class Diagram

23

Candidate Classes (5)

Advert

cost

Cam paigncam paign nam ebudgetbalance

Cam paignInvoice

Client

client nam e What about ‘total advert cost’?

total advert cost

Probably a derived attribute of Campaign

24

Identify non-functional requirements - Usability

• What is the level of experience for the user?

• What user interface standards are familiar to the user?

• What documentation should be provided to the user?

Reliability: robustness, safety and security

• How reliable, robust , and available the system should be?

• How much data the system can loose?• How much time the system can remain offline?• How the system should handle exceptions?• Are there any safety or security requirements for the

system?

Performance

• How responsive should the system be?• Are any user tasks time critical?• How many concurrent users there will be?• How large is the data store?• What is the worst latency acceptable?

Supportability: maintainability and portability

• What are the foreseen extensions to the system?

• Who maintains the system ?

• Are there plans to port the system to different software or hardware environments?

Implementation

• Are there constraints on hardware platform?

• Are there constraints imposed by maintenance team?

Interface

• Should the system interact with existing systems?

• How are the data imported/exported to the system?

Packaging

• How installs the system?

• How it will be installed?

Legal

• Should the system be licensed?

• Are any liability issues associated with system failure?

• Should other used components/software be licensed?