swe311_ch07 (071) software & software engineering slide 1 chapter 7 requirements engineering

SWE311_Ch07 (071) Software & Software Engineering Slide 1

Chapter 7Chapter 7Requirements EngineeringRequirements Engineering


ObjectivesObjectives

Introduce Requirements Engineering conceptsIntroduce Requirements Engineering concepts

Introduce major tasks of Requirements Introduce major tasks of Requirements EngineeringEngineering


Overview Overview Requirements engineering helps software engineers better understand the Requirements engineering helps software engineers better understand the

problems they are trying to solve. problems they are trying to solve. Building an elegant computer solution that ignores the customer's needs Building an elegant computer solution that ignores the customer's needs

helps no one. helps no one. It is very important to understand the customer's wants and needs before It is very important to understand the customer's wants and needs before

you begin designing or building a computer-based solution. you begin designing or building a computer-based solution. The requirements engineering process begins with inception, moves on to The requirements engineering process begins with inception, moves on to

elicitation, elaboration, negotiation, problem specification, and ends with elicitation, elaboration, negotiation, problem specification, and ends with review or validation of the specification. review or validation of the specification.

The intent of requirements engineering is to produce a written The intent of requirements engineering is to produce a written understanding of the customer's problem. understanding of the customer's problem.

Several different work products might be used to communicate this Several different work products might be used to communicate this understanding (user scenarios, function and feature lists, analysis models, understanding (user scenarios, function and feature lists, analysis models, or specifications). or specifications).


Requirements EngineeringRequirements Engineering

RequirementRequirement: A function, constraint or other property that : A function, constraint or other property that the system must provide to fill the needs of the system’s the system must provide to fill the needs of the system’s intended user(s)intended user(s)

Engineering:Engineering: implies that systematic and implies that systematic and repeatable techniques should be used to ensure repeatable techniques should be used to ensure that system requirements are complete, consistent, that system requirements are complete, consistent, relevant . . . etc.relevant . . . etc.

RequirementRequirement EngineeringEngineering covers all of the activities covers all of the activities involved in discovering, documenting, and involved in discovering, documenting, and maintaining a set of requirements for a system.maintaining a set of requirements for a system.

RERE means that requirements for a product are means that requirements for a product are defined, managed and tested systematicallydefined, managed and tested systematically


Requirements EngineeringRequirements Engineering Must be adapted to the needs of a specific process, Must be adapted to the needs of a specific process,

project, product, or people doing the work. project, product, or people doing the work.

Begins during the software engineering communication Begins during the software engineering communication activity and continues into the modeling activity. activity and continues into the modeling activity.

In some cases requirements engineering may be In some cases requirements engineering may be abbreviated, but it is never abandoned. abbreviated, but it is never abandoned.

It is essential that the software engineering team It is essential that the software engineering team understand the requirements of a problem before the team understand the requirements of a problem before the team tries to solve the problem.tries to solve the problem.


Types of RequirementsTypes of Requirements

Functional Functional requirement requirement

A requirement that specifies a function or service A requirement that specifies a function or service that a system must be capable of performing from that a system must be capable of performing from user’s point of view.user’s point of view.

Non-functional Non-functional requirement requirement

A requirement that describes the property of the A requirement that describes the property of the system including performance, reliability, usability system including performance, reliability, usability etc.etc.


What do we achieve by end of REWhat do we achieve by end of RE

Full understanding of what the stakeholders really Full understanding of what the stakeholders really need of the systemneed of the system

Complete and accurate representation of that to be Complete and accurate representation of that to be communicated to system developerscommunicated to system developers


Characteristics of a Good Characteristics of a Good RequirementRequirement

Clear and Unambiguous Clear and Unambiguous standard structurestandard structure has only one possible interpretationhas only one possible interpretation Not more than one requirement in one sentenceNot more than one requirement in one sentence

CorrectCorrect A requirement contributes to a real needA requirement contributes to a real need

UnderstandableUnderstandable A reader can easily understand the meaning of the A reader can easily understand the meaning of the

requirementrequirement VerifiableVerifiable

A requirement can be testedA requirement can be tested CompleteComplete ConsistentConsistent TraceableTraceable


Why is Getting Good Requirements Hard?Why is Getting Good Requirements Hard?

Stakeholders don’t know what they really want.Stakeholders don’t know what they really want. Stakeholders express requirements in their own Stakeholders express requirements in their own

terms.terms. Different stakeholders may have conflicting Different stakeholders may have conflicting

requirements.requirements. Organisational and political factors may Organisational and political factors may

influence the system requirements.influence the system requirements. The requirements change during the RE process. The requirements change during the RE process.

New stakeholders may emerge and the business New stakeholders may emerge and the business environment change.environment change.


Requirements Engineering TasksRequirements Engineering Tasks

InceptionInception

ElicitationElicitation

ElaborationElaboration

NegotiationNegotiation

SpecificationSpecification

Requirements Requirements ValidationValidation

Requirements managementRequirements management


Requirements Engineering-IRequirements Engineering-I

InceptionInception—ask a set of questions that establish —ask a set of questions that establish …… basic understanding of the problembasic understanding of the problem the people who want a solutionthe people who want a solution the nature of the solution that is desired, and the nature of the solution that is desired, and the effectiveness of preliminary the effectiveness of preliminary

communication and collaboration between the communication and collaboration between the customer and the developercustomer and the developer


ElicitationElicitation

ElicitationElicitation—elicit requirements from all stakeholders—elicit requirements from all stakeholders Find out from customers what the product Find out from customers what the product

objectives areobjectives are what is to be done what is to be done how the product fits into business needs, and how the product fits into business needs, and how the product is used on a day to day basis how the product is used on a day to day basis


ElaborationElaboration—create an analysis model that identifies —create an analysis model that identifies data, function and behavioral requirementsdata, function and behavioral requirements Focuses on developing a refined technical model of Focuses on developing a refined technical model of

software functions, features, and constraints using the software functions, features, and constraints using the information obtained during inception and elicitation information obtained during inception and elicitation

ElaborationElaboration


NegotiationNegotiation

NegotiationNegotiation—agree on a deliverable system that is —agree on a deliverable system that is realistic for developers and customersrealistic for developers and customers Requirements are categorized and Requirements are categorized and

organized into subsetsorganized into subsets Relations among requirements identifiedRelations among requirements identified Requirements reviewed for correctnessRequirements reviewed for correctness Requirements prioritized based on Requirements prioritized based on

customer needs customer needs


Requirements Engineering-IIRequirements Engineering-II SpecificationSpecification—can be any one (or more) of —can be any one (or more) of

the following:the following: A written documentA written document A set of modelsA set of models A formal mathematical specificationA formal mathematical specification A collection of user scenarios (use-cases)A collection of user scenarios (use-cases) A prototypeA prototype


Requirements ValidationRequirements Validation

Requirements ValidationRequirements Validation—formal technical review —formal technical review mechanism that looks formechanism that looks for errors in content or interpretationerrors in content or interpretation areas where clarification may be requiredareas where clarification may be required missing informationmissing information inconsistencies (a major problem when large inconsistencies (a major problem when large

products or systems are engineered)products or systems are engineered) conflicting or unrealistic (unachievable) conflicting or unrealistic (unachievable)

requirements. requirements.


Requirements managementRequirements management Set of activities that help project team to identify, control, and track Set of activities that help project team to identify, control, and track

requirements and changes as project proceeds requirements and changes as project proceeds

Many of these activities are identical to those that make up the Many of these activities are identical to those that make up the software configuration management (SCM) process software configuration management (SCM) process

Requirements are first identified, tagged with a unique identifier and Requirements are first identified, tagged with a unique identifier and classified by type (functional, data, behavioral, interface, or output) classified by type (functional, data, behavioral, interface, or output)

Traceability tables (e.g., features, source, dependency, subsystem, Traceability tables (e.g., features, source, dependency, subsystem, interface) are developed and updated any time a requirement is interface) are developed and updated any time a requirement is modified) modified)

Database systems are invaluable in helping software teams track Database systems are invaluable in helping software teams track requirement changesrequirement changes


Traceability TablesTraceability Tables

Features traceability table (shows how requirements relate to Features traceability table (shows how requirements relate to customer observable features) customer observable features)

Source traceability table (identifies source of each Source traceability table (identifies source of each requirement) requirement)

Dependency traceability table (indicate relations among Dependency traceability table (indicate relations among requirements) requirements)

Subsystem traceability table (requirements categorized by Subsystem traceability table (requirements categorized by subsystem) subsystem)

Interface traceability table (shows requirement relations to Interface traceability table (shows requirement relations to internal and external interfaces)internal and external interfaces)


Initiating Requirements Engineering ProcessInitiating Requirements Engineering Process Identify stakeholdersIdentify stakeholders

““who else do you think I should talk to?”who else do you think I should talk to?” Recognize multiple points of viewRecognize multiple points of view Work toward collaborationWork toward collaboration The first questionsThe first questions

Who is behind the request for this work?Who is behind the request for this work? Who will use the solution?Who will use the solution? What will be the economic benefit of a successful What will be the economic benefit of a successful

solutionsolution Is there another source for the solution that you need?Is there another source for the solution that you need?


The next set of questionsThe next set of questions enable developers to better enable developers to better understand the problem and the customer's perceptions of the understand the problem and the customer's perceptions of the solution solution How would you characterize good output form a successful solution? How would you characterize good output form a successful solution?

What problem(s) will this solution address? What problem(s) will this solution address?

Can you describe the business environment in which the solution will Can you describe the business environment in which the solution will be used? be used?

Will special performance constraints affect the way the solution is Will special performance constraints affect the way the solution is approached?approached?


The final set of questionsThe final set of questions focuses on communication focuses on communication effectiveness effectiveness Are you the best person to give "official" answers to these questions? Are you the best person to give "official" answers to these questions?

Are my questions relevant to your problem? Are my questions relevant to your problem?

Am I asking too many questions? Am I asking too many questions?

Can anyone else provide additional information? Can anyone else provide additional information?

Should I be asking you anything else?Should I be asking you anything else?


Eliciting RequirementsEliciting Requirements meetings are conducted and attended by both software engineers and meetings are conducted and attended by both software engineers and

customerscustomers rules for preparation and participation are establishedrules for preparation and participation are established A flexible agenda is suggested A flexible agenda is suggested a "facilitator" (can be a customer, a developer, or an outsider) controls a "facilitator" (can be a customer, a developer, or an outsider) controls

the meetingthe meeting a "definition mechanism" (can be work sheets, flip charts, or wall a "definition mechanism" (can be work sheets, flip charts, or wall

stickers or an electronic bulletin board, chat room or virtual forum) is stickers or an electronic bulletin board, chat room or virtual forum) is usedused

the goal is the goal is to identify the problemto identify the problem propose elements of the solutionpropose elements of the solution negotiate different approaches, andnegotiate different approaches, and specify a preliminary set of solution requirementsspecify a preliminary set of solution requirements


Eliciting RequirementsEliciting Requirements

Use QFD to prioritize

requirements

informally prioritize

requirements

formal prioritization?

Create Use-cases

yes noElic it requirements

write scenario

define actors

complete template

draw use-case diagram

Conduct FASTmeetings

Make lists offunctions, classes

Make lists ofconstraints, etc.


Quality Function DeploymentQuality Function Deployment

Function deploymentFunction deployment determines the “value” (as perceived by determines the “value” (as perceived by the customer) of each function required of the systemthe customer) of each function required of the system

Information deploymentInformation deployment identifies data objects and events identifies data objects and events Task deploymentTask deployment examines the behavior of the system examines the behavior of the system Value analysisValue analysis determines the relative priority of requirements determines the relative priority of requirements


User-scenarios/use-cases User-scenarios/use-cases

describe how the system will be used describe how the system will be used

Developers and users create a set of usage threads for Developers and users create a set of usage threads for the system to be constructedthe system to be constructed


Elicitation Work ProductsElicitation Work Products a statement of need and feasibility.a statement of need and feasibility.

a bounded statement of scope for the system or product.a bounded statement of scope for the system or product.

a list of customers, users, and other stakeholders who a list of customers, users, and other stakeholders who participated in requirements elicitation participated in requirements elicitation

a description of the system’s technical environment.a description of the system’s technical environment.

a list of requirements (preferably organized by function) a list of requirements (preferably organized by function) and the domain constraints that apply to each.and the domain constraints that apply to each.

a set of usage scenarios that provide insight into the use of a set of usage scenarios that provide insight into the use of the system or product under different operating conditions.the system or product under different operating conditions.

any prototypesany prototypes developed to better understand developed to better understand requirementsrequirements.


Use-CasesUse-Cases A collection of user scenarios that describe the thread of usage of a systemA collection of user scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an “actor”—a person or Each scenario is described from the point-of-view of an “actor”—a person or

device that interacts with the software in some waydevice that interacts with the software in some way Each scenario answers the following questions:Each scenario answers the following questions:

Who is the primary actor, the secondary actor (s)?Who is the primary actor, the secondary actor (s)? What are the actor’s goals?What are the actor’s goals? What preconditions should exist before the story begins?What preconditions should exist before the story begins? What main tasks or functions are performed by the actor?What main tasks or functions are performed by the actor? What extensions might be considered as the story is described?What extensions might be considered as the story is described? What variations in the actor’s interaction are possible?What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change?What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external Will the actor have to inform the system about changes in the external

environment?environment? What information does the actor desire from the system?What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?Does the actor wish to be informed about unexpected changes?


Use-case DrawbacksUse-case Drawbacks

Lack of formality in use-case descriptions Lack of formality in use-case descriptions

Not all systems have explicitly defined actors Not all systems have explicitly defined actors

Use-cases are not inherently object-oriented Use-cases are not inherently object-oriented

Developers have a tendency to functionally decompose use-Developers have a tendency to functionally decompose use-cases.cases.


Use Case Modeling A full use-case model comprise of:A full use-case model comprise of:

A diagram, describing relations between use-cases and actors.A diagram, describing relations between use-cases and actors. A document describing the use case in detailsA document describing the use case in details

Use Case A sequence of actions a system performs to yield an observable result

of value to a particular actor Stevens/Pooley: A task which an actor needs to perform with the help

of the system

Actor Someone or something outside the system that interacts with the system A user of the system in a particular role Actors are NOT part of the systemActors are NOT part of the system


Use Case Diagram ObjectiveUse Case Diagram Objective

1.1. Create a semi-formal model of the functional requirementsCreate a semi-formal model of the functional requirements

2.2. Analyze and define:Analyze and define: ScopeScope External interfacesExternal interfaces Scenarios and reactionsScenarios and reactions


What Makes Good Use-Case Specification?What Makes Good Use-Case Specification?

Lack of ambiguityLack of ambiguity Each requirement must be interpreted in a single manner.Each requirement must be interpreted in a single manner.

CompletenessCompleteness They should cater for all They should cater for all currentcurrent demands of the system. demands of the system.

ConsistencyConsistency Requirements should not conflictRequirements should not conflict with each other. If there are, with each other. If there are,

tradeoffs must be detected and discussed.tradeoffs must be detected and discussed.

Avoid designAvoid design Requirements should raise a need, not answer it. (Why?)Requirements should raise a need, not answer it. (Why?)


Use Cases

Each use case has a name In the UML, a use case is represented as an ovalIn the UML, a use case is represented as an oval A family (or set, or class) of scenarios

A sequence of interactions A set of different but related scenarios

Documenting Use Cases A UML Diagram showing all of them

Actors are stick-figures; use cases are ovals For each use case define using English A clear textual description A set of scenarios in outline form


Relationships between Use Cases

UML supports two relationships between two use cases <<includes>>

before UML 1.3 <<includes>> was <<uses>> The source use case always includes the actions specified in the

target use case

<<extends>> The target use case my include the behavior of the source use

case


Documenting Use CasesDocumenting Use Cases

Use case nameUse case name Each use case is given a name.Each use case is given a name.

SummarySummary A brief description of the use case, typically one or two sentences.A brief description of the use case, typically one or two sentences.

Dependency Dependency Description of whether the use case depends on other use cases, that is, Description of whether the use case depends on other use cases, that is,

whether it includes or extends another use case.whether it includes or extends another use case.

ActorsActors Names of the actors that participate in the use caseNames of the actors that participate in the use case


Documenting Use Cases Documenting Use Cases (Cont’d)(Cont’d)

PreconditionsPreconditions One or more conditions that must be true at the start of the use caseOne or more conditions that must be true at the start of the use case

DescriptionDescription Description of the main sequence of the use case, which is the most Description of the main sequence of the use case, which is the most

usual sequence of interactions between the actor and the system.usual sequence of interactions between the actor and the system.

AlternativesAlternatives Description of alternative branches off the main sequence.Description of alternative branches off the main sequence.

PostconditionPostcondition Condition that is always true at the end of the use case if the main Condition that is always true at the end of the use case if the main

sequence has been followed.sequence has been followed.


PreconditionsPreconditions

• One or more conditions that must be true at the start of the use One or more conditions that must be true at the start of the use casecase

• ExamplesExamples User account existsUser account exists User has enough money in her accountUser has enough money in her account There is enough disk spaceThere is enough disk space


Post-ConditionsPost-Conditions

Condition that is always true at the end of the use case if the Condition that is always true at the end of the use case if the main sequence has been followed.main sequence has been followed.

ExamplesExamples Money was transferred to the user accountMoney was transferred to the user account User is logged inUser is logged in The file is saved to the hard-diskThe file is saved to the hard-disk


Use-Cases – Common MistakesUse-Cases – Common Mistakes

Complex diagramComplex diagram No systemNo system No actorNo actor Too many user interface detailsToo many user interface details

““User types ID and password, clicks OK or hits Enter”User types ID and password, clicks OK or hits Enter” Very low goal detailsVery low goal details

User provides nameUser provides name User provides addressUser provides address User provides telephone numberUser provides telephone number ……


Example 1: Validate PIN Use Example 1: Validate PIN Use CaseCase

Use case nameUse case name Validate PINValidate PIN

SummarySummary System validates customer PIN.System validates customer PIN.

ActorActor ATM CustomerATM Customer

PreconditionPrecondition ATM is idle, displaying a Welcome message.ATM is idle, displaying a Welcome message.


Example 1: Validate PIN Example 1: Validate PIN Use Case Use Case (Cont’d)(Cont’d)

DescriptionDescription

1.1. Customer inserts the ATM card into the Card Reader.Customer inserts the ATM card into the Card Reader.

2.2. If the system recognizes the card, it reads the card number.If the system recognizes the card, it reads the card number.

3.3. System prompts customer for PIN numberSystem prompts customer for PIN number

4.4. Customer enters PINCustomer enters PIN

5.5. System Checks the expiration date and whether the card is lost or System Checks the expiration date and whether the card is lost or stolen.stolen.

6.6. If card is valid, the system then checks whether the user-entered PIN If card is valid, the system then checks whether the user-entered PIN matches the card PIN maintained by the system.matches the card PIN maintained by the system.

7.7. numbers match, the system checks that accounts are accessible with the numbers match, the system checks that accounts are accessible with the ATM card.ATM card.

8.8. System displays customer accounts and prompts customer for System displays customer accounts and prompts customer for transaction type: Withdrawal, Query, or Transfer.transaction type: Withdrawal, Query, or Transfer.


Example 1: Validate PIN Example 1: Validate PIN Use Case Use Case (Cont’d)(Cont’d)

AlternativesAlternatives If the system does not recognize the card, the card is ejected.If the system does not recognize the card, the card is ejected. If the system determines that the card date has expired, the card is confiscated.If the system determines that the card date has expired, the card is confiscated. If the system determines that the card has been reported lost or stolen, the card If the system determines that the card has been reported lost or stolen, the card

is confiscated.is confiscated. If the customer-entered PIN does not math the PIN number for this card, the If the customer-entered PIN does not math the PIN number for this card, the

system re-prompts for the PIN.system re-prompts for the PIN. If the customer enters the incorrect PIN three times, the system confiscates the If the customer enters the incorrect PIN three times, the system confiscates the

card.card. If the customer enters Cancel, the system cancels the transaction and ejects the If the customer enters Cancel, the system cancels the transaction and ejects the

card.card. PostconditionPostcondition

Customer PIN has been validated.Customer PIN has been validated.


Example 2: Withdraw Funds Example 2: Withdraw Funds Use CaseUse Case

Use case nameUse case name

Withdraw FundsWithdraw Funds

SummarySummary

Customer withdraws a specific amount of funds from a valid bank account.Customer withdraws a specific amount of funds from a valid bank account.

ActorActor

ATM CustomerATM Customer

DependencyDependency

Include Include Validate PINValidate PIN abstract use case abstract use case

PreconditionPrecondition

ATM is idle, displaying a Welcome message.ATM is idle, displaying a Welcome message.


Example 2: Withdraw Funds Example 2: Withdraw Funds Use Case Use Case (Cont’d)(Cont’d)

DescriptionDescription

1.1. Include Include Validate PINValidate PIN abstract use case. abstract use case.

2.2. Customer selects Withdrawal, enters the amount, and selects the account Customer selects Withdrawal, enters the amount, and selects the account number.number.

3.3. System checks whether customer has enough funds in the account and whether System checks whether customer has enough funds in the account and whether the daily limit will not be exceeded.the daily limit will not be exceeded.

4.4. If all checks are successful, system authorizes dispensing of cash.If all checks are successful, system authorizes dispensing of cash.

5.5. System dispenses the cash amount.System dispenses the cash amount.

6.6. System prints a receipt showing transaction number, transaction type, amount System prints a receipt showing transaction number, transaction type, amount withdrawn, and account balance.withdrawn, and account balance.

7.7. System ejects card.System ejects card.

8.8. System displays Welcome Message.System displays Welcome Message.


Example 2: Withdraw Funds Example 2: Withdraw Funds Use Case Use Case (Cont’d)(Cont’d)

AlternativesAlternatives If the system determines that the account number is invalid, it displays If the system determines that the account number is invalid, it displays

an error message and ejects the card.an error message and ejects the card. If the system determines that there are insufficient funds in the If the system determines that there are insufficient funds in the

customer’s account, it displays an apology and eject the card.customer’s account, it displays an apology and eject the card. If the system determines that the maximum allowable daily withdrawal If the system determines that the maximum allowable daily withdrawal

amount has been exceeded, it displays an apology and ejects the card.amount has been exceeded, it displays an apology and ejects the card. If the ATM is out of funds, the system displays an apology, ejects the If the ATM is out of funds, the system displays an apology, ejects the

card, and shuts down the ATM.card, and shuts down the ATM.

PostconditionPostcondition Customer funds have been withdrawn.Customer funds have been withdrawn.


The sections of a use caseThe sections of a use case

NameName. The name should implicitly express the user's intent or . The name should implicitly express the user's intent or purpose of the use case purpose of the use case

Identifier [Optional]Identifier [Optional]. A unique identifier, such as "UC1701," . A unique identifier, such as "UC1701," that can be used in other project artifacts to refer to the use that can be used in other project artifacts to refer to the use case. case.

DescriptionDescription. Several sentences summarizing the use case. . Several sentences summarizing the use case.

Actors [Optional]Actors [Optional]. The list of actors associated with the use . The list of actors associated with the use case. case.


The sections of a use case (cont.)The sections of a use case (cont.)

Status [Optional]Status [Optional]. An indication of the status of the use case, . An indication of the status of the use case, typically one of: work in progress, ready for review, passed typically one of: work in progress, ready for review, passed review, or failed review. review, or failed review.

FrequencyFrequency. How often this use case is . How often this use case is invokedinvoked by the actor. by the actor. Example, once per each user login or once per month. Example, once per each user login or once per month.

PreconditionsPreconditions. A list of the conditions, if any, that must be . A list of the conditions, if any, that must be met before a use case may be invoked. met before a use case may be invoked.

PostconditionsPostconditions. A list of the conditions, if any, that will be . A list of the conditions, if any, that will be true after the use case finishes successfully.true after the use case finishes successfully.



Extended use case [Optional]Extended use case [Optional]. The use case that this use case extends (if . The use case that this use case extends (if any). any).

Included use cases [Optional]Included use cases [Optional]. A list of the use cases this one includes.. A list of the use cases this one includes.

Assumptions [Optional]Assumptions [Optional]. Any important assumptions about the domain . Any important assumptions about the domain that you have made when writing this use case. that you have made when writing this use case.

Basic course of actionBasic course of action. The main path of logic an actor follows through a . The main path of logic an actor follows through a use case. Often referred to as the use case. Often referred to as the main pathmain path because it describes how the because it describes how the use case works when everything works as it normally should. use case works when everything works as it normally should.

Alternate courses of actionAlternate courses of action. The infrequently used paths of logic in a use . The infrequently used paths of logic in a use case, paths that are the result of an alternate way to work, an exception, or case, paths that are the result of an alternate way to work, an exception, or an error condition.an error condition.



Change history [Optional]Change history [Optional]. Details about when the use case . Details about when the use case was modified, why, and by whom. was modified, why, and by whom.

Issues [Optional]Issues [Optional]. A list of issues or action items, if any, that . A list of issues or action items, if any, that are related to the development of this use case. are related to the development of this use case.

DecisionsDecisions . A list of critical decisions pertaining to the content . A list of critical decisions pertaining to the content of the use case. It is important to record these decisions to of the use case. It is important to record these decisions to maintain a maintain a group memorygroup memory. .


An ExampleAn Example

A complete example may be found in the A complete example may be found in the following sitefollowing site http://www.cs.gordon.edu/courses/cs211/ATMExample/ihttp://www.cs.gordon.edu/courses/cs211/ATMExample/i

ndex.htmlndex.html


Negotiating RequirementsNegotiating Requirements

Identify the key stakeholdersIdentify the key stakeholders These are the people who will be involved in the negotiationThese are the people who will be involved in the negotiation

Determine each of the stakeholders “win conditions”Determine each of the stakeholders “win conditions” Win conditions are not always obviousWin conditions are not always obvious

NegotiateNegotiate Work toward a set of requirements that lead to “win-win”Work toward a set of requirements that lead to “win-win”


Key pointsKey points

It's not a competition It's not a competition Map out a strategy Map out a strategy Listen actively Listen actively Focus on other party's interests Focus on other party's interests Don't let it get personal Don't let it get personal Be creative Be creative Be ready to commitBe ready to commit


Validating Requirements-IValidating Requirements-I Is each requirement consistent with the overall objective for the Is each requirement consistent with the overall objective for the

system/product?system/product? Have all requirements been specified at the proper level of abstraction? Have all requirements been specified at the proper level of abstraction?

That is, do some requirements provide a level of technical detail that is That is, do some requirements provide a level of technical detail that is inappropriate at this stage?inappropriate at this stage?

Is the requirement really necessary or does it represent an add-on feature Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?that may not be essential to the objective of the system?

Is each requirement bounded and unambiguous?Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a Does each requirement have attribution? That is, is a source (generally, a

specific individual) noted for each requirement? specific individual) noted for each requirement? Do any requirements conflict with other requirements?Do any requirements conflict with other requirements?


Validating Requirements-IIValidating Requirements-II

Is each requirement achievable in the technical environment that will house the Is each requirement achievable in the technical environment that will house the system or product?system or product?

Is each requirement testable, once implemented?Is each requirement testable, once implemented?

Does the requirements model properly reflect the information, function and Does the requirements model properly reflect the information, function and behavior of the system to be built.behavior of the system to be built.

Has the requirements model been “partitioned” in a way that exposes progressively Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.more detailed information about the system.

swe311_ch07 (071) software & software engineering slide 1 chapter 7 requirements engineering

Documents