View
228
Download
2
Category
Preview:
Citation preview
SWE311_Ch07 (071) Software & Software Engineering Slide 1
Chapter 7Chapter 7Requirements EngineeringRequirements Engineering
SWE311_Ch07 (071) Software & Software Engineering Slide 2
ObjectivesObjectives
Introduce Requirements Engineering conceptsIntroduce Requirements Engineering concepts
Introduce major tasks of Requirements Introduce major tasks of Requirements EngineeringEngineering
SWE311_Ch07 (071) Software & Software Engineering Slide 3
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).
SWE311_Ch07 (071) Software & Software Engineering Slide 4
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
SWE311_Ch07 (071) Software & Software Engineering Slide 5
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 6
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 7
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
SWE311_Ch07 (071) Software & Software Engineering Slide 8
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
SWE311_Ch07 (071) Software & Software Engineering Slide 9
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 10
Requirements Engineering TasksRequirements Engineering Tasks
InceptionInception
ElicitationElicitation
ElaborationElaboration
NegotiationNegotiation
SpecificationSpecification
Requirements Requirements ValidationValidation
Requirements managementRequirements management
SWE311_Ch07 (071) Software & Software Engineering Slide 11
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
SWE311_Ch07 (071) Software & Software Engineering Slide 12
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
SWE311_Ch07 (071) Software & Software Engineering Slide 13
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
SWE311_Ch07 (071) Software & Software Engineering Slide 14
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
SWE311_Ch07 (071) Software & Software Engineering Slide 15
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
SWE311_Ch07 (071) Software & Software Engineering Slide 16
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 17
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
SWE311_Ch07 (071) Software & Software Engineering Slide 18
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)
SWE311_Ch07 (071) Software & Software Engineering Slide 19
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?
SWE311_Ch07 (071) Software & Software Engineering Slide 20
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?
SWE311_Ch07 (071) Software & Software Engineering Slide 21
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?
SWE311_Ch07 (071) Software & Software Engineering Slide 22
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
SWE311_Ch07 (071) Software & Software Engineering Slide 23
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 24
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
SWE311_Ch07 (071) Software & Software Engineering Slide 25
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
SWE311_Ch07 (071) Software & Software Engineering Slide 26
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 27
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?
SWE311_Ch07 (071) Software & Software Engineering Slide 28
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 29
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
SWE311_Ch07 (071) Software & Software Engineering Slide 30
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
SWE311_Ch07 (071) Software & Software Engineering Slide 31
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?)
SWE311_Ch07 (071) Software & Software Engineering Slide 32
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
SWE311_Ch07 (071) Software & Software Engineering Slide 33
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
SWE311_Ch07 (071) Software & Software Engineering Slide 34
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
SWE311_Ch07 (071) Software & Software Engineering Slide 35
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 36
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
SWE311_Ch07 (071) Software & Software Engineering Slide 37
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
SWE311_Ch07 (071) Software & Software Engineering Slide 38
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 ……
SWE311_Ch07 (071) Software & Software Engineering Slide 39
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 40
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 41
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 42
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 43
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 44
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 45
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 46
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 47
The sections of a use case (cont.)The sections of a use case (cont.)
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.
SWE311_Ch07 (071) Software & Software Engineering Slide 48
The sections of a use case (cont.)The sections of a use case (cont.)
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. .
SWE311_Ch07 (071) Software & Software Engineering Slide 49
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
SWE311_Ch07 (071) Software & Software Engineering Slide 50
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”
SWE311_Ch07 (071) Software & Software Engineering Slide 51
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
SWE311_Ch07 (071) Software & Software Engineering Slide 52
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?
SWE311_Ch07 (071) Software & Software Engineering Slide 53
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.
Recommended