Beruflich Dokumente
Kultur Dokumente
Matthew Dailey
Computer Science and Information Management Asian Institute of Technology
Requirements
1 / 54
Readings
Readings for these lecture notes: - Larman (2005), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edition, Chapters 16. Some material c Larman (2005).
Requirements
2 / 54
Outline
Requirements
3 / 54
Introduction
It is dicult to deliver quality software that meets stakeholder needs! OOAD is one method for tackling the problem by capturing the design in a way that is easy to communicate, review, implement, and evolve.
Requirements
4 / 54
Introduction
The UP
OOAD need to be performed within a software development process. The Unied Process is an iterative, risk-driven, architecture-centric approach to software development.
Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Time Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.
3 weeks (for example) Iterations are fixed in length, or timeboxed. The system grows incrementally.
Outline
Requirements
6 / 54
OOAD Overview
To develop a system using OOAD, we need to know an OO language and UML, but just as important we need to think in terms of objects. OOAD is mainly about assigning responsibilities to classes of objects. OOA means nding the objects and concepts in the problem domain.
Plane domain concept tailNumber visualization of domain concept
public class Plane { private String tailNumber; public List getFlightHistory() {...} }
Requirements
7 / 54
OOAD Overview
Rolls
Die faceValue 2
Includes
Requirements
8 / 54
OOAD Overview
OOD means dening the software components, their responsiblities, and how they collaborate to fulll the requirements.
Requirements
9 / 54
OOAD Overview
Requirements
10 / 54
OOAD Overview
We will use the Unied Modeling Language to communicate domain and design models. UML has 3 uses in software engineering: As a sketch tool: informal, incomplete diagrams sketched on a whiteboard to explore tricky problems. As a blueprint tool: detailed diagrams used for reverse engineering and code generation (forward engineering). As an end-to-end programming language: still in development. We will favor agile approaches that use UML as a sketch tool. Dont overdo UML!
Requirements
11 / 54
OOAD Overview
We begin with analysis. At this point, the classes we derive will be conceptual, representing real world things in the problem domain.
DiceGame 1 Includes 2 Die faceValue Conceptual Perspective (domain model) Raw UML class diagram notation used to visualize real-world concepts.
Specification or Implementation Perspective (design class diagram) Raw UML class diagram notation used to visualize software elements.
Later the model will be elaborated into software classes or design classes providing a solution, and implementation classes in a real OO language.
Requirements
12 / 54
Outline
Requirements
13 / 54
UP Overview
The Unied Process is an iterative development process. Iterative development is now standard in the industry. Compared to traditional waterfall methods, iterative development has proven to reduce defects, increase productivity, and increase project success rates. The basic idea is short iterations that are xed in length or timeboxed. Depending on implementation in the organization, UP, the UP can be low ceremony and agile.
Requirements
14 / 54
UP Overview
Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Time
Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test
Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.
3 weeks (for example) Iterations are fixed in length, or timeboxed. The system grows incrementally.
Requirements
15 / 54
UP Overview
Iterative development is not new. The spiral process has been around since the 1980s. Many big projects in the 60s and 70s used iterative techniques. The benet is it allows us to embrace change. On every iteration, shareholders have the opportunity to say yes, its what I asked for, but... Typical iterations are 26 weeks. They should be as short as possible. Be careful to prevent the iterations from becoming waterfall phases!
Requirements
16 / 54
UP Overview
Example process implementation: Two-day requirements workshop to detail the 10% of your use cases with the higest business value, greatest risk, and higest architectural impact. This is the end of the inception phase. Plan the rst iteration. Pick a subset of the detailed scenarios to design, implement and test, in a short period, e.g. 4 weeks. Do 2 days of modeling on whiteboards. Program, test, and integrate continuously. Stick to the plan! One week before end of the iteration: decide what will make it into the current iteration and postpone remainder to the next. Demo for stakeholders and request feedback. Repeat until 80%90% of the use cases are fully detailed and the architecture is baselined. This is the end of the elaboration phase.
Matthew Dailey (CSIM-AIT) Requirements 17 / 54
UP Overview
1 2 3 4 5 ... 20 requirements workshops Imagine this will ultimately be a 20iteration project. In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.
requirements
requirements
software
software
90%
90%
50% 20% 2% Iteration 1 30% 5% Iteration 2 a 3-week iteration 8% Iteration 3 10% Iteration 4 20% Iteration 5
week 1 M T W Th F
week 2 M T W Th F
week 3 M T W Th F
final check-in and codefreeze for the iteration baseline Use-case modeling during the workshop
UP Overview
The UP is risk driven: in early iterations we identify and mitigate the most signicant risks. The UP is client driven: we build the features the client cares about most rst. The UP is architecture centric: we focus on the architecturally signicant use cases rst.
Requirements
19 / 54
UP Overview
UP is compatible with the agile manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Resonding to change over following a plan
Requirements
20 / 54
UP Overview
When modeling, we should apply the principles of agility: Modeling is for understanding and communication, not documentation. Model the dicult tricky parts of the design, not the simple parts. Use simple tools like whiteboards before CASE tools. Dont model alone and rotate the whiteboard marker. Do parallel models, e.g. static and dynamic. Use good enough notation dont drown yourself in the details. Be ready to throw your models away and reverse engineer from the code you wrote. There is no such thing as analysts, developers, and testers take ownership, from modeling to testing. Teams should be horizontal, not vertical.
Matthew Dailey (CSIM-AIT) Requirements 21 / 54
UP Overview
Example of some practical modeling:
Requirements
22 / 54
UP Overview
Best practices for UP application: Attack high risk, high value issues rst. Continuously engage users. Develop a cohesive core architecture in early iterations. Continuously verify quality test early, often, and realistically. Apply the use cases where appropriate. Do some visual modeling. Carefully manage requirements. Practice change request and conguration management.
Requirements
23 / 54
UP Overview
The phases in the UP are: Inception: work out the initial vision, business case, and scope, with vague estimates. Elaboration: rene the vision, develop the core architecture, resolve major risks, further detail the requirements. Construction: work on the lower-risk, easier elements. Transition: beta test and deploy
Requirements
24 / 54
UP Overview
inc.
elaboration
construction
transition
release A stable executable subset of the final product. The end of each iteration is a minor release.
final production release At this point, the system is released for production use.
Requirements
25 / 54
UP Overview
Each phase in the UP involves all disciplines to an extent, with dierent weightings in dierent phases. In this course, we focus on business modeling, requirements analysis, and design.
Requirements
26 / 54
UP Overview
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable. Sample UP Disciplines Business Modeling Focus of this book Requirements Design Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations
Note that although an iteration includes work in most disciplines, the relative effort an emphasis chang over time. This example is suggestive, not literal.
Requirements
27 / 54
UP Overview
You are doing it wrong if you notice You detail all the requirements before starting to program. You spend days or weeks on UML modeling before starting to program. You spend more time creating documents than programming.
Requirements
28 / 54
Outline
Requirements
29 / 54
Inception
Here we consider requirements analysis, which has the most weight during the elaboration phase. Inception is not requirements! Inception focuses on What is the vision and business case? Is it feasible? Buy or build? Whats the rough cost? Do it or not?
Requirements
30 / 54
Inception
See the text for inception artifacts. Most are optional! The only UML produced in inception will possibly be use case diagrams, but they are not necessary. Most of the artifacts are pure text.
Requirements
31 / 54
Inception
You are executing inception incorrectly if: Inception takes more than a few weeks. You dene the architecture. You try to do requirements, design, and implementation. There is no business case or vision. Most use cases are detailed. No use cases are detailed.
Requirements
32 / 54
Outline
Requirements
33 / 54
Requirements Analysis
In UP, we manage requirements and expect them to change. Studies show that on average, 25% of requirements change during the project! Other studies have found that 2/3 of the features specied in waterfall requirements documents are never or rarely used!
Requirements
34 / 54
Requirements Analysis
Fig. 5.1
Poor user input 13%
Incomplete requirements 12% Other 50% Changing requirements 12% Poor technical skills 7% Poor staffing 6%
Requirements
35 / 54
Requirements Analysis
One breakdown for requirements is FURPS+: Functional Usability Reliability Performance Supportability Implementation Interface Operations Packaging Legal Sometimes we make special note of quality attributes, and sometimes we distinguish between functional and non-functional requirements.
Matthew Dailey (CSIM-AIT) Requirements 36 / 54
Requirements Analysis
The key requirements artifacts are: The Use Case Model The Supplementary Specication (a place for non-functional requirements and features that dont t in the use case model) The Glossary (denition of noteworthy terms) The Vision (an overview and high-level summary of the requirements) The Business Rules (cross-project requirements such as tax laws) Where to put these artifacts? A project wiki works well.
Requirements
37 / 54
Requirements Analysis
Use cases are text stories that are useful for discovering and recording requirements. See example (p63):
Requirements
38 / 54
Requirements Analysis
Sample UP Artifact Relationships Domain Model Business Modeling Sale date ... 1 1..* Sales LineItem quantity objects, attributes, associations Use-Case Model Process Sale
Process Sale Cashier
... ...
Vision
1. Customer arrives ... 2. Cashier makes new sale. 3. ... Use Case Text system events : System
Glossary
Requirements
: Cashier
system operations
Design Model
: ProductCatalog
: Sale
Design
Requirements
39 / 54
Requirements Analysis
Denitions: Actor: something with behavior, outside the system under discussion (SuD). Scenario: a specic sequence of actions and interactions. Sometimes called a use case instance. Use case: a collection of related success/failure scenarios. The use case model includes the use cases along with an optional use case diagram showing the names of the use cases, the actors, and their relationships.
Requirements
40 / 54
Requirements Analysis
Use cases are not object oriented, but are crucial to OOAD. Use cases are the recommended central mechanism for discovering requirements, especially the functional requirements.
Requirements
41 / 54
Requirements Analysis
Actor types: Primary: has user goals which the SuD must fulll. Supporting: provides service to the SuD. Ostage: interested but not directly involved. E.g. the tax agency.
Requirements
42 / 54
Requirements Analysis
Enterprise Selling Things Checkout Service Sales Tax Agency Goal: Collect taxes on sales Sales Activity System Customer POS System
Cashier
Requirements
43 / 54
Requirements Analysis
A use case can be written in one of 3 notations: Brief: only the main scenario, with a short description. Casual: multiple scenarios described by short paragraphs. Fully-dressed: fully elaborated with supporting sections. For the use case model, Larman uses the Cockburn notation.
Requirements
44 / 54
Requirements Analysis
A fully-dressed use case has these sections: Use case name Scope Level Primary actor Stakeholders and interests Preconditions Success guarantee (postconditions) Main success scenario Extensions Special requirements Technology and data variations list Frequency of occurrence Miscellaneous See the example, pp. 6872.
Matthew Dailey (CSIM-AIT) Requirements 45 / 54
Requirements Analysis
Always remember that your use cases will be wrong! They will change as the project matures. There are other notations besides Cockburns. It can be adapted to your organization and projects needs. Guidelines for writing use cases: Essential style (no UI) Keep it terse Treat the system as a black box. Come from the actor and actor-goal perspective.
Requirements
46 / 54
Requirements Analysis
Finding use cases: Choose the system boundary Identify primary actors Identify goals for each primary actor Dene use cases in terms of user goals
Requirements
47 / 54
Requirements Analysis
Tests to see if your proposed use case is a good one: The boss test The EBP (elementary business process) test: a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state, e.g. Approve Credit or Price Order. The size test (310 pages, fully dressed)!
Requirements
48 / 54
Requirements Analysis
Diagram your use cases, only for summary purposes. The biggest mistake novices make is too much emphasis on the diagram and not enough emphasis on the text. Sometimes UML activity diagrams will be useful for complex use cases, but dont overuse them.
Requirements
49 / 54
Requirements Analysis
system boundary NextGen POS communication
Payment Authorization Service Handle Returns actor Tax Calculator actor Accounting System actor HR System
actor
Cashier
Manage Security
System Administrator
...
Requirements
50 / 54
Requirements Analysis
For a use case context diagram, limit the use cases to user-goal level use cases. NextGen Show computer system actors with an alternate notation to human actors.
Process Sale
Cashier
...
Requirements
51 / 54
Requirements Analysis
NextGen Process Sale system Payment Payment Authorization Authorization Service Service actor Payment Authorization Service
Some UML alternatives to illustrate external actors tha other computer systems. The class box style can be u for any actor, computer or human. Using it for compute actors provides visual distinction.
...
Requirements
52 / 54
Requirements Analysis
Requirements
53 / 54
Requirements Analysis
When
Once during inception. Short; do not try to define or polish all requirements. Several times during elaboration iterations.
Where
At a requirements workshop.
January
February
Use Case: Capture a Sale ... Main Success Scenario: 1. ... 2. ... 3. ... Extensions:
Use Case: Handle Returns ... Main Success Scenario: 1. ... 2. ... 3. ... Extensions:
Developer
Requirements
54 / 54