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