June 23, 2005

Project Estimation based on Requirements Analysis with UML/SysML

INCOSE Heartland Chapter

Jorge Buenfil

June 23, 2005

Presentation Outline

1. Requirements-centric system analysis and design

2. Requirements management techniques to support project cost/time estimation

3. Requirements Management Plan

4. Traceability of requirements into the model and back

5. Requirements verification & validation

6. Operational Concepts document

7. Cost/time estimation based on the UML model

June 23, 2005

Why use UML/SysML to estimate schedule/cost?

Schedule/cost estimation is not only for program managers and project leads. At some point or another we all get asked “how long will that take you to do?”, or “Will this change have a huge impact on our plan?”

Lines-of-Code (LOC) method no longer works Other methods are overtly complicated and unwieldy (i.e.,

COCOMO-COnstructive COst MOdel) and people don’t use them often

UML is good for bridging the gap between engineering and management

We might already be using UML for design

June 23, 2005

TL Originating Requirements

“There is an intersection between a seldom-used farm road and a busy highway. A farmer has difficulty getting across the highway, so we are to install a traffic-light system. Design a controller for this traffic-light system. Normally, the highway light shall be green and the farm road light shall be red. When a sensor signals that a tractor is on the farm road, the highway light shall change to yellow. After a short-time interval (STI, nominally 10 seconds) the highway light shall change to red and the farm road light shall change to green. The farm road light shall stay green until the tractor clears the sensor or after a long-time interval (LTI, nominally 50 seconds), whichever comes first. Then the farm road light shall become yellow. After a short time interval the farm road light shall become red and the highway light shall become green. The system shall stay in that state for a least a long time interval. After a long time interval the highway light shall be switched when the sensor detects a tractor. A timer that produces output signals after short time intervals and long time intervals will be available. It can be restarted at anytime.”

June 23, 2005

Requirements-centric system analysis and design

Think outside of engineering Requirements are the closest thing we initially have to measure

the project effort During analysis (and before design) derived requirements should

be negotiated with the stakeholders (especially the customer) Need to move from flat structures for requirements documents to

multi-level requirement representations Need to move away from ambiguity coming from free-text

requirements into more precise languages, such as UML Requirements attributes hold the key to cost and schedule

determination and monitoring

June 23, 2005

Requirements for the TL example

June 23, 2005

Traffic Light (TL) ExampleFarm road

Farm road

sensor

sensor

Highway

Highway

June 23, 2005

Requirements Management Plan

The Requirements Management Plan is a document that outlines your approach to managing requirements. It must address the concerns of:

Stakeholders Business Objectives Security/Access privileges by each team member Required documentation to be generated for upper management or

standard committees The Requirements Management Plan specifies the different types

of requirements (functional, regulatory, safety, product family, performance, etc.) and their respective attributes

June 23, 2005

Requirements management techniques to support project initial cost/time estimation

First of all, get all the requirements (or as many as possible) early on

Group requirements into more manageable units Add requirement attributes for:

Estimated difficulty (easy, medium, hard) Volatility (firm, tentative) Estimated time to completion (# hours) Confidence on the estimation (fudge factor) Dependencies on other requirements Estimated Cost (Computed field)

Create a traceability matrix to show which requirements depend on which others (to help estimate the impact of changes)

June 23, 2005

Traceability of requirements into the model and back

A UML model helps visualize the main components of a system and the way those components implement requirements

Requirements are traced into Use Cases Use Cases are traced into State Charts and/or Activity Diagrams State Charts and/or Activity Diagrams are traced into “classes” or

other types of modules that can be independently created and tested.

Classes and other modules generate code or other artifacts (FPGAs, ASICs, etc.)

Requirement attributes are filled and fine-tuned as work progresses, which in turn affect the project schedule and cost estimation

June 23, 2005

Use Case for the TL example

June 23, 2005

Requirements verification & validation

Requirements verification refers to the task of finding out if the implementation of the system corresponds with the requirements

Requirements validation refers to the task of finding out if the requirements accurately represent the needs of the customer

The UML helps in these two tasks by: Establishing a one-to-one correspondence between the

requirements and the design, then either a tool would automatically generate most of the code, or the code would be created manually to implement the design. Test cases would be used to link design and code.

Showing in a clear way how the originating requirements indicate a solution to a problem that the customer can review to validate if that is what he/she wants.

June 23, 2005

Analysis Classes for the TL example

Timer

RoadSensor

TrafficLight

TrafficLight

TrafficLightController

+HighwayTrafficLightChangeLight

+FarmTrafficLight

setTrafficLight

June 23, 2005

Design Classes for the TL example

Timer

RoadSensor

TrafficLightController

GreenLightYellowLightRedLight

TrafficLight

+HighwayTrafficLight +FarmTrafficLight

setTrafficLight

1

1

1

11

1

1

1

1

1

1

1

June 23, 2005

Statechart for the TL example

Normal

entry/ ^Timer.setTimer(50)entry/ ^FarmRoadTrafficLight.setLight(Red)entry/ ^HighwayTrafficLight.setLight(Green)

Triggered

entry/ ^HighwayTrafficLight.setLight(Yel low)entry/ ^Timer.setTimer(10)

Farm Road Traffic Enabled

entry/ ^HighwayTrafficLight.setLight(Red)entry/ ^FarmRoadTrafficLight.setLight(Green)entry/ ^Timer.setTimer(50)

timeOut

Resetting

entry/ setFarmRoadTrafficLightYellowentry/ ^Timer.setTimer(10)

timeOut

roadSensorTriggered[ timeOut ]

<<requirement>>

R1: Normal ly the highway light shall be green and the farm road shal l be red.

satisfy

<<requirement>>

R2: When a sensor signals that a tractor is on the farm road, the highway l ight shal l change to yellow.

satisfy

<<requirement>>

R3: After a short-time interval (STI, nominally 10 seconds) the highway light shall change to red and the farm road light shall change to green.

satisfy

<<requirement>>

R4: The farm road l ight shall stay green unti l the tractor clears the sensor or after a long-time interval (LTI, nominally 50 seconds), whichever comes first. Then the farm road light shall become yellow.

roadSensorClearedtimeOut

satisfy

<<requirement>>

R5: After a short-time interval the farm road light shall become red and the highway light shall become green.

<<requirement>>

R6: The system shal l stay in that state for at least a long time interval.

satisfy

satisfy

<<requirement>>

R7: After a long time interval the highway light shall be switched when the sensor detects a tractor.

satisfy

June 23, 2005

Creation of an Operational Concepts document

An Operational Concepts (also known as Concept of Operations-CONOPS) document is a vehicle to represent the general operation of the system being created. This document forms the basis for system design and is the first step towards representing the system in UML.

Questions that the Operational Concepts document should answer:

What functions will the system perform? When will the system be required to perform its functions and for

how long? Where will the system be used? How will the system accomplish its objective?

The UML is a good language to use for the Operational Concepts document because it represents a view of the world where the system interacts with people and other systems.

June 23, 2005

Traffic Light (TL) ExampleFarm road

Farm road

sensor

sensor

Highway

Highway

June 23, 2005

Deployment Diagram for the TL example

Traf f icLightControllerProcessor

Farm Road Sensor 1

Farm Road Traf f ic Light 1

Highway Traf f ic Light 1

Timer

Farm Road Sensor 2

Farm Road Traf f ic Light 2

EIA232

RJ-11

Highway Traf f ic Light 2

RJ-11

RJ-11

RJ-11

EIA232

June 23, 2005

Cost/time estimation based on the UML model

The key to cost/time estimation is the identification of discrete work units (DWUs).

DWUs correspond to small entities in the UML (typically classes) that have a single purpose, have a name (identity), and a public interface that declares what services it can perform when activated and how to request those services

DWUs can theoretically be assigned to an individual, but in practice can be implemented by a team.

DWUs can contain several requirements DWUs can be estimated individually in terms of hours of work,

and from there obtain a cost estimation can be obtained by looking at the level of difficulty of the work (which translates to a level of pay)

June 23, 2005

References

Jesse Daniels and Terry Bahill. The Hybrid Process That Combines Traditional Requirements and Use Cases. Systems Engineering-The Journal of The International Council on Systems Engineering, Vol. 7, No. 4, pp. 303-319, October 2004.

A. Terry Bahill, et al. The Design-Methods Comparison Problem, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, Vol. 28, No. 1, pp. 80-103, February 1998.

Dean Leffingwell and Don Widrig. Managing Software Requirements. A Unified Approach. Addison-Wesley. USA 2000.

Martin Fowler. UML Distilled, third edition. A Brief Guide to the Standard Object Modeling Language. Addison-Wesley. USA 2004.

June 23, 2005

References

Benjamin S. Blanchard and Wolter J. Fabrycky. Systems Engineering and Analysis, third edition. Prentice Hall International Series in Industrial and Systems Engineering. USA 1998.

Grady Booch, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley. Object Technology Series, 1999.

James Rumbaugh, Ivar Jacobson, Grady Booch. The Unified Modeling Language Reference Manual. Addison-Wesley Object Technology Series, 1999.

Gamma, Erich et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.

June 23, 2005

Questions?Questions?