Project Estimation based on Requirements Analysis with UML/SysML

1. Project Estimation based on Requirements Analysis with UML/SysML INCOSE Heartland Chapter Jorge Buenfil

2. Presentation Outline • Requirements-centric system analysis and design • Requirements management techniques to support project cost/time estimation • Requirements Management Plan • Traceability of requirements into the model and back • Requirements verification & validation • Operational Concepts document • Cost/time estimation based on the UML model

3. 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

4. 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.”

5. 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

6. Requirements for the TL example

7. Traffic Light (TL) Example

8. 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

9. 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)

10. 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

11. Use Case for the TL example

12. 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.

13. Analysis Classes for the TL example

14. Design Classes for the TL example

15. Statechart for the TL example

16. 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.

17. Traffic Light (TL) Example

18. Deployment Diagram for the TL example

19. 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)

20. 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 ComparisonProblem, 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.

21. 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.

22. Questions?