software analysis and design i
DESCRIPTION
SOFTWARE ANALYSIS AND DESIGN I. 12/10/07 Vít STINKA. LESSON AGENDA. Requirements management Visual modeling Analysis & Design Requirements traps. MOTIVATION. REQUIREMENTS MANAGEMENT. SYSTEM REQUIREMENTS CAPTURE. Requirement - PowerPoint PPT PresentationTRANSCRIPT
SOFTWAREANALYSIS AND DESIGN I12/10/07 Vít STINKA
© UNICORN 2004
LESSON AGENDA
Requirements management Visual modeling Analysis & Design Requirements traps
© UNICORN 2004
MOTIVATION
REQUIREMENTS MANAGEMENT
© UNICORN 2004
SYSTEM REQUIREMENTS CAPTURE
RequirementA feature that the system must have or a constraint that it must satisfy to be accepted by the customer
Requirements capture (elicitation, ...)The specification of the system in a way that the customer/user understands
CHALLENGE:CHALLENGE: How to bridge the gap?
Requires the collaboration ofseveral groups of participants with
different backgroundsGAPGAPGAPGAP
© UNICORN 2004
TYPES OF REQUIREMENTS: FURPS+
Functionality Usability Reliability Performance Supportability + Technological constraints
© UNICORN 2004
FUNCTIONALITY
Functionality the system must by able to perform Functionality description - inputs, outputs,
transformations, interaction Usually Use Case model
Other requirements - „non-functional“
© UNICORN 2004
USABILITY
Ergonomy, requirements about usability Aesthetics User interface consistency Help, on-line help, context sensitive help Wizards and smart-guides User manual(s) Course materials
© UNICORN 2004
RELIABILITY
Frequency and severity of failure Recoverability Predictability
for. example free hard drive space
Accuracy Mean time between failure (MTBF) Security
© UNICORN 2004
PERFORMANCE
Number of concurrent users Speed Efficiency Availability Throughput Response time Recovery time Resource usage
© UNICORN 2004
SUPPORTABILITY
Testability Extensibility Adaptability Maintainability Compatibility Configurability Serviceability Installability Localizability (internationalization)
© UNICORN 2004
+ TECHNOLOGICAL CONSTRAINTS
Design constraints Modeling tools, standards...
Implementation constraints Standards Programming languages Database integrity policies Resource limits Operation environments
Interface requirements External systems Formats, timings...
Physical requirements Material, shape, size, weight... Like physical network configurations
© UNICORN 2004
SRS
The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system.
When using use-case modeling, this artifact consists of
Package(s) containing use cases of the use-case model Applicable Supplementary Specifications.
As soon as possible...
© UNICORN 2004
SYSTEM REQUIREMENTS CAPTURE System requirements capture constructs two main models:
Domain model: describes the application’s static data requirements
Use-case model: describes the application’s dynamic processing requirements
The domain model and use-case model are developed over several development increments
Inception phase: identify most domain model elements and use cases in order to delimit the system and scope the project (detail the most critical use cases (less than 10%))
Elaboration phase: capture most (80%) of the remaining requirements
Construction phase: capture remaining requirements and implement the system
Transition phase: no requirements capture unless there are changing requirements
© UNICORN 2004
REQUIREMENTS - THE LEVEL OF ABSTRACTION
© UNICORN 2004
WHAT IS HARD ABOUT REQUIREMENTS MANAGEMENT?
Requirements are not always obvious, and can come from many sources
Requirements are not always easy to express clearly in words There are many different types of requirements at different
levels of detail The number of requirements can become unmanageable if not
controlled Requirements are related to one another and also to other
deliverables of the software engineering process Requirements have unique properties or property values. For
example, they are neither equally important nor equally easy to meet
There are many interested parties, which means requirements need to be managed by cross-functional groups of people
Requirements change
© UNICORN 2004
Reasons for failure of/problems with software development:
Incomplete requirements 13.1%
Lack of user involvement 12.4%
Lack of resources 10.6%
Unrealistic expectations 9.9%
Lack of executive support 9.3%
Changing requirements and specifications 8.7%
Lack of planning 8.1%
System no longer needed 7.5%
IMPORTANCE OF REQUIREMENTS CAPTURE
Requirements capture involved in most cases
© UNICORN 2004
IMPORTANCE OF REQUIREMENTS CAPTUREcost to findand fix a defect
logscale
1
10
100
Reqmts
0.75
Design
1.00
Code
1.50
Test
3.00
Systemtest
10.00
Fielduse
60-100
BUT, requirements capture is VERY DIFFICULT!
© UNICORN 2004
SYSTEM REQUIREMENTS CAPTURE PROCESS
Architect
SystemAnalyst
Use-CaseSpecifier
Find Classesand Associations
PrioritizeUse Cases
PrototypeUser-Interface
DetailUse Cases
Structure theUse-Case Model
User-InterfaceDesigner
Find Actors andUse Cases
DomainAnalyst
Detail Classesand Associations
© UNICORN 2004
FOUR VARIABLES
Quality, quantity, time & budget are requirements Consider these variables when planning phases
Keyvariables
Quality
Time
Budget
Quantity
The variablesmust be balanced
VISUAL MODELING
© UNICORN 2004
ARCHITECTING A DOG HOUSE
Can be built by one personRequires
Minimal modelingSimple processSimple tools
© UNICORN 2004
ARCHITECTING A HOUSE
Built most efficiently and timely by a teamRequires
ModelingWell-defined processPower tools
© UNICORN 2004
WE WANT TO ARCHITECT A HIGH RISE... :)
© UNICORN 2004
MODELING A HOUSE
© UNICORN 2004
VISUAL MODELING
A technique for information sharing and presentation using pictures
Supports communication „A single picture can sometimes tell more than
several pages of text“ Business processes Context of the system Organization and/or behavior of code System‘s deployment
There is a need of standard, well understood common language
© UNICORN 2004
ADVANTAGES OF VISUAL MODELING
Better problem understanding Better communication
User-to-developer Developer-to-developer Team-to-management
Easy to find some kind of errors Simulation Code generation
Managing the complexity
Model - the abstraction of reality
© UNICORN 2004
UNIFIED MODELING LANGUAGE
De Facto standard for visual modeling and object-oriented analysis and design
Managed by OMG (Object Management Group, www.omg.org)
UML is a language for Visualization Specification Construction Documentation
© UNICORN 2004
FORMER METHODS
Functional modeling Structured analysis&design Data flow diagrams Flow charts
Data modeling Entity relationships
Focus on behavior only or data only Sensitivity to requirements changes All parts are mutually connected (CRUD matrix for
example) Maintanance problems
© UNICORN 2004
EVOLUTION OF THE UML
Meyer
Before and after conditions
HarelStatecharts
Gamma, et al
Frameworks and patterns
HP FusionOperation descriptions and message numbering
Embley
Singleton classes andhigh-level view
Wirfs-Brock
ResponsibilitiesOdell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE
© UNICORN 2004
NOTATION AND PROCESS
Notation - a visual language Similar to music notes or electrotechnical schemas Describes how to express the information, not how to
manage the work or find the information
Process - a methodology Telĺs how to work Defines the organization of roles, artifacts and activities
For system‘s definition you won‘t use only one picture
© UNICORN 2004
UML DIAGRAMS
Use Case Diagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
Statecharts
SequenceDiagrams
Class Diagrams
ActivityDiagrams
Model
© UNICORN 2004
WHAT UML IS NOT?
Not textual Not fixed Not a process No guarantee for succes
© UNICORN 2004
PRINCIPLES OF MODELING
The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped
Every model may be expressed at different levels of precision
The best models are connected to reality No single model is sufficient. Every nontrivial
system is best approached through a small set of nearly independent models
Booch, Jacobson, Rumbaugh
REQUIREMENTS TRAPS
© UNICORN 2004
TRAP 1: CONFUSION OVER “REQUIREMENTS”
Stakeholders discuss “requirements” withno adjectives in front
Project sponsor presents a high-levelconcept as “the requirements”
User interface screens are viewed as“the requirements”
User provides “requirements,” butdevelopers still don’t know what to build
Requirements focus just on features and functionality
Symptoms
© UNICORN 2004
THREE LEVELS OF SOFTWARE REQUIREMENTS
#1: BusinessRequirements
Vision and Scope Document
#2: UserRequirements
Use Case Document
#3:FunctionalRequirements
Software Requirements Specification
Constraints
Other NonfunctionalRequirements
SystemRequirements
QualityAttributes
BusinessRules
© UNICORN 2004
TRAP 2: INADEQUATE CUSTOMER INVOLVEMENT
Some user classes are overlooked
Some user classes don’t have a voice
User surrogates attempt to speak for users
User managers Marketing Developers
Developers have to make many requirements decisions
Customers reject the product when they first see it
Symptoms
© UNICORN 2004
USER-DEVELOPER COMMUNICATION PATHS
User DeveloperRequirementsAnalyst
MarketingProcuringCustomer
ProductChampion
Help Desk
SystemArchitect
CustomerManager
© UNICORN 2004
TRAP 3: VAGUE & AMBIGUOUS REQUIREMENTS
Readers interpret a requirement in severaldifferent ways
Requirements are missing information thedeveloper needs
Requirements are not verifiable Developer has to ask many questions Developer has to guess a lot
Symptoms
© UNICORN 2004
TRAP 3: VAGUE & AMBIGUOUS REQUIREMENTS
Formally inspect requirement documents Write conceptual test cases against requirements Model requirements to find knowledge gaps Use prototypes to make requirements more tangible Define terms in a glossary Avoid ambiguous words:
minimize, maximize, optimize, rapid, user-friendly, simple, intuitive, robust, state-of-the-art, improved, efficient, flexible, several, and/or, etc., include, support...
Solutions
© UNICORN 2004
TRAP 4: UNPRIORITIZED REQUIREMENTS
All requirements are critical! Different stakeholders interpret “high”
priority differently After prioritization, 95% are still high Developers don’t want to admit
they can’t do it all It’s not clear which requirements
to defer during the “rapid descoping phase.”
Symptoms
L M H
100%
80%
60%
40%
20%
0%
© UNICORN 2004
REQUIREMENTS PRIORITIZATION
Need to understand which requirements are most important and most urgent
Not everything can be top priority! Setting priorities will help you
Work on the right things first Make tradeoff decisions Deal with added and changed requirements
Need to bypass politics and emotion Prioritize early and continuously Develop priorities collaboratively
costvalue
© UNICORN 2004
TRAP 5: BUILDING FUNCTIONALITY NO ONE USES
Users demand certain features, then no one uses them
Proposed functionality isn’t related to business tasks Developers add functions because
“the users will love this” Customers don’t distinguish “chrome” from “steel”
Symptoms
© UNICORN 2004
TRAP 5: BUILDING FUNCTIONALITY NO ONE USES
Derive functional requirements from use cases Trace every functional requirement back to its origin Identify user classes who will benefit from each feature Analytically prioritize requirements, use cases, or
features Have customers rate value (benefit and penalty) Have developers estimate cost and risk Avoid requirements with high cost and low value
Solutions
© UNICORN 2004
TRAP 6: ANALYSIS PARALYSIS
Requirements development seems to go on forever New versions of the SRS are continually released Requirements are never baselined All requirements are modeled six ways from
Sunday Design and coding can’t start until the SRS is
perfect
Symptoms
© UNICORN 2004
TRAP 6: ANALYSIS PARALYSIS
Remember: the product is software, not an SRS Select an appropriate development life cycle
Staged release, evolutionary prototyping, time-boxing
Decide when requirements are good enough Acceptable risk of proceeding with construction Reviewed by analyst, developers, testers, and customers
Model just the complex or uncertain parts of the system
Don’t include final user interface designs in SRS
Solutions
© UNICORN 2004
TRAP 7: SCOPE CREEP
New requirements are continually added Schedule doesn’t change No more resources provided
Product scope is never clearly defined Requirement changes sneak in through the back door Proposed requirements come, and go, and come back Scope issues are debated during SRS reviews Sign-off is just a game
Symptoms
© UNICORN 2004
TRAP 7: SCOPE CREEP
Determine root causes of the scope creep Document the product’s vision and scope Define system boundaries and interfaces Follow the change control process for all changes Improve requirements elicitation methods Follow a meaningful baselining process Renegotiate commitments when requirements change
Solutions
© UNICORN 2004
TRAP 8: INADEQUATE CHANGE PROCESS
No change process is defined Some people bypass the change process
Talk to buddies on the inside Implement rejected changes Work is done on proposed changes before they’re
approved
New functionality becomes evident during testing Unclear change request status Changes aren’t communicated to all those affected It’s not clear who makes change decisions
Symptoms
© UNICORN 2004
TRAP 8: INADEQUATE CHANGE PROCESS
Define a practical change control process Set up a Change Control Board
Diverse group Makes binding change decisions
Use a tool to collect, track, and communicate changes Problem or issue tracking tools work well A tool is not a process!
Establish and enforce change control policies Compare priorities against remaining requirements
Solutions
© UNICORN 2004
TRAP 9: INSUFFICIENT CHANGE IMPACT ANALYSIS
People agree to make changes hastily Change is more complex than anticipated Change takes longer than promised Change isn’t technically feasible Change causes project to slip Developers keep finding more system
components affected by the change
Symptoms
© UNICORN 2004
TRAP 9: INSUFFICIENT CHANGE IMPACT ANALYSIS
Systematically analyze the impact of each proposed change
Identify all possible tasks Consider other implications of accepting the change Estimate effort and schedule impact
Use requirements traceability information Identify all affected system components
Estimate costs and benefits before making commitments
Solutions
© UNICORN 2004
TRAP 10: INADEQUATE VERSION CONTROL
Accepted changes aren’t incorporated into SRS You can’t distinguish different SRS versions
Different versions have the same date Identical documents have different dates
People work from different SRS versions Implement canceled features Test against the wrong requirements
Change history and earlier document versions are lost
Symptoms
© UNICORN 2004
TRAP 10: INADEQUATE VERSION CONTROL
Merge changes into the SRS Adopt a versioning scheme for documents Place requirements documents under version control
Restrict read/write access Make current versions available read-only to all
Communicate revisions to all who are affected Use a requirements management tool
Record complete history of every requirement change. SRS becomes a report from the database
Solutions
© UNICORN 2004
KEYS TO EXCELLENT SOFTWARE REQUIREMENTS
Educated developers, managers, and customers
A collaborative customer-developer partnership
Understanding different kinds of requirements
Iterative, incremental requirements development
Standard requirements document templates
Formal and informal requirements reviews
Writing test cases against requirements
Analytical requirements prioritization
Practical, effective change management