Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Lecture 7:Requirements Engineering
and Use Cases
Software System Design and ImplementationITCS/ITIS 6112/8112 001Fall 2008
Dr. Jamie PaytonDepartment of Computer ScienceUniversity of North Carolina at Charlotte
Sept. 16, 2008
2
Announcements
Homework 1 is available Due Tuesday, Sept. 23 at 5:00 pm
• No late submissions accepted for credit
Submit by email to [email protected]• Electronic copy only, preferably in PDF
3
Lecture Overview
Requirements engineering activities Requirements change management Requirements and use cases
4
Requirements Engineering Activities
Inception Elicitation Elaboration/Analysis
Negotiation
Specification Validation
5
Requirements Engineering Activities
Inception Elicitation Elaboration/Analysis
Negotiation
Specification Validation
6
Requirements Validation Techniques
Requirements reviews Systematic manual analysis of the requirements
Prototyping Using an executable model of the system to check
requirements• Covered in Chapter 17
Test-case generation Developing tests for requirements to check testability
• If difficult to design tests, requirement will be difficult to Implement Validate
7
Reviewing Requirements
Individual Requirements Verifiability
• Is the requirement realistically testable?
Comprehensibility• Is the requirement properly understood?
Traceability• Is the origin of the requirement clearly stated?
Adaptability• Can the requirement be changed without a large impact on
other requirements?
8
Reviewing Requirements
Collection of requirements (SRS) Consistency
• Are there any requirements conflicts?
Completeness• Are all functions required by the customer included?
Realism• Can the requirements be implemented given available budget
and team?
9
Requirements Management
Requirements change during a project Need to understand, control, and track changes
• Policies Requirements identification Change management process Traceability policy CASE tool support
10
Requirements Change Management
Should apply to all proposed changes to therequirements
Principal stages Problem analysis
• Discuss requirements problem and propose change Change analysis and costing
• Assess effects of change on other requirements Change implementation
• Modify documentation to reflect change
11
Traceability
Traceability is concerned with the relationships betweenrequirements, their sources and the system design
Requirements should be uniquely identified to aid in traceability Naming convention should reflect traceability relationships
Traceability relationships Source traceability
• Links from requirements to stakeholders who proposed theserequirements
Requirements traceability• Links between dependent requirements
Design traceability• Links from the requirements to the design
12
Traceability Matrix
Relates requirements to Stakeholders Other requirements System features Design modules
• Subsystems• Interfaces
Req.
id
1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 D R
1.2 D D D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R
Creation Manual for small projects Generated from database in
large projects
Traceability and requirement relationships
13
CASE Tools forRequirements Change Management
Basic productivity tools Word processors, spreadsheets, databases
Workbenches CASE Spec
• www.analysttool.com• Free demo
Borland Caliber Analyst• http://www.borland.com/us/products/caliber/index.html• Free trial
DOORS (by IBM)• http://www.telelogic.com/corp/products/doors/• Free trial
14
The Software RequirementsSpecification Document
The official statement of what is required of thesystem developers
Should include: a definition of user requirements a specification of the system requirements
15
Requirements Document Structure
Preface Intended audience Version Change summary
Introduction Project overview
Glossary Requirements
User requirements definition System requirements specification
Appendices Hardware, software related requirements
16
Lecture Overview
Requirements engineering activities Requirements change management Requirements and use cases
17
Developing Use Cases
Use Case Scenario-based approach to capturing functional
requirements Model behavior as a sequence of actions
Describes how an actor interacts with the system Actor (UML terminology)
• Represents role people or device play when using the system• External to system (system is not an actor)
Provides an observable result of value to the actor• Related to some tangible amount of work
18
Use Cases in UML
Use Case Diagram Represents a product’s use cases and actors involved in each
use case Models a static view of a system Catalogs all use cases
Graphical Notation
19
Use Case Diagram Example
University Library System Who are the actors? What do they want to do with the system?
Automated Carwash Who are the actors? What do they want to do with the system?
20
Use Case Specification Guidelines (1)
Never make the product an actor Name actors with noun phrases Name use cases with verb phrases Each use case must be associated with at least one
actor Each actor must be associated with at least one use
case Associations only link actors to use cases
21
Use Case Specification Guidelines (2)
Draw use case diagrams on a single page Organize by actor, problem domain, or solution categories
Make uses cases of similar size/complexity Use cases should achieve something useful (a goal)
for an actor If it isn’t useful, you’re specifying use cases at a level that is
too detailed!
22
Use Case Model
Use Case Diagrams Static model Capture user-level requirements Names product use cases and actors
Use Case Descriptions Specifies actors’ interactions with product Model operational-level requirements in greater detail Dynamic model
• Textual descriptions of activities Will use a standard template
• Supplemented by activity, statechart diagrams Order of interactions Possible courses of interaction
23
Writing Use Case Descriptions
Finding the actors Stakeholders are a superset of human use case actors
Preconditions Only state conditions that are necessary and important E.g., user must be logged in to system
Postconditions Must be true, no matter which flow is executed E.g., Account balance is greater than or equal to $0.00
Trigger Sometimes the first step in the use case
24
Writing Use Case Descriptions(2)
Basic Flow Choose a simple and common activity flow Start at the beginning and write the flow to successful
completion• Number each step• Write each step in simple, declarative sentence
Basic Flow Example Fingerprint Access System
• Enter Secure Facility Use Case
25
Organizing the Use Case Model
May have overlap in use case model Use cases may be specified at different levels of granularity Use cases may have variant
Want to reduce redundancy to promote consistency Can extract common and related behavior among use cases Can specify relationships between use cases
Use Case Relationships in UML Generalization
• One use case is a specialization of another Include
• One use case is a part of another Extend
• One use case extends the behavior of a core use case
26
Generalization
A specific (child) use case inherits behavior and meaning of a more general (parent)
use case May add to behavior or override behavior or more general
(parent) use case
Customer
Perform Transaction
Withdraw Money Deposit Money
27
Include
One use case explicitly incorporates another An included use case is always instantiated by larger containing use
case• Not based on meeting conditions• Never stands alone!• Executes exactly as stated
Used to extract common behaviors from multiple use cases into asingle description
Customer
Withdraw Money
Validate UserCheck Balance<<include>>
28
Extend
A use case implicitly incorporates the behavior ofanother Extension is not a stand alone use case Captures conditional behavior
• Instantiated only if triggering condition is met
CustomerPay Overdraft feePay Invoice
<<extend>>
29
Writing Use Cases with Extensions
Extensions Find the branch points Think of alternatives to finish the activity/task How might the use case end in success? How might the use case end in failure?
Treat extensions as a separate use case Condition is the trigger Extension steps are basic flow Completing use case or returning to branch point are goals
Extension Example Fingerprint Access System
• Enter Secure Facility Use Case
30
A bank wishes to design a billing and payment system. Thesystem will use the Internet to send orders, invoices, andpayments between buyers and sellers. The bank’s motivation fordeveloping the system is to attract new customers by offering alow payment-processing fee. The bank will also be able to reduceits wage costs by processing payment requests automaticallythrough the Internet instead of manually through cashiers.
The motivations for buyers and sellers are to reduce costs,paperwork, and processing time. The payment of invoices will behandled, for instance, between the buyer’s computer and theseller’s computer. Buyers and sellers will also have a betteroverview of the status of their invoices and payments.
Example