This chapter discusses software development processes, project planning, and effort estimation. It introduces several key concepts: - Software development processes involve a series of steps and activities that produce intended outputs. Common process models include waterfall, iterative development, and agile methods. - Project planning involves tracking progress, organizing personnel, and estimating effort and schedule. Tools like Gantt charts, histograms, and expenditure tracking can be used. - Effort estimation methods include expert judgment, algorithmic techniques like COCOMO II, and machine learning approaches. Estimates should be refined repeatedly as uncertainty decreases over the project lifecycle.

1. Chapter 2
Objectives
• What we mean by a “process”
• Software development products, processes, and resources
• Several models of the software development process
• Tools and techniques for process modeling
2.1 The Meaning of Process
• A process: a series of steps involving activities, constraints, and resources that produce an
intended output of some kind
• A process involves a set of tools and techniques
Process Characteristics
• Prescribes all major process activities
• Input:
– Uses resources (e.g., customer input, specifications),
– subject to set of constraints (such as schedule, platform reqts)
• Output: Produces intermediate and final products (e.g., models)
• Structure:
– May be composed of subprocesses
– with hierarchy or links
• Properties:
– Each process activity has entry and exit criteria
– Activities are organized in sequence, so timing is clear
– Each process guiding principles, including goals of each activity
– Constraints may apply to an activity, resource or product
The Importance of Processes
• Impose consistency and structure on a set of activities
• Guide us to understand, control, examine, and improve the activities
• Enable us to capture our experiences and pass them along
2.2 Software Process Models
Reasons for Modeling a Process
• To form a common understanding
• To find inconsistencies, redundancies, omissions
• To find and evaluate appropriate activities for reaching process goals

2. • To tailor a general process for a particular situation in which it will be used
Software Life Cycle
• When a process involves building software, the process may be referred to as software life
cycle
– Requirements analysis and definition
– System (architecture) design
– Program (detailed/procedural) design
– Writing programs (coding/implementation)
– Testing: unit, integration, system
– System delivery (deployment)
– Maintenance
Software Development Process Models
• Waterfall model
• V model
• Prototyping model
• Operational specification
• Transformational model
• Phased development: increments and iteration
• Spiral model
• Agile methods
Waterfall Model
• One of the first process development models proposed
• Works for well understood problems with minimal or no changes in the requirements
• Simple and easy to explain to customers
• It presents
– a very high-level view of the development process
– Sequence of process activities
• Each major phase is marked by milestones and deliverables (artifacts)

3. • There is no iteration in waterfall model
• Most software developments apply a great many iterations
Sidebar 2.1 Drawbacks of the Waterfall Model
• Provides no guidance how to handle changes to products and activities during development
(assumes requirements can be frozen)
• Views software development as manufacturing process rather than as creative process
• There is no iterative activities that lead to creating a final product
• Long wait before a final product
Waterfall model with Prototyping

4. V Model
Prototyping Model
• Allows repeated investigation of the requirements or design
• Reduces risk and uncertainty in the development

5. Operational Specification Model
• Requirements are executed (examined) and their implication evaluated early in the development
process
• Functionality and the design are allowed to be merged
Transformational Model
• Fewer major development steps
• Applies a series of transformations
– Change data representation
– Select algorithms
– Optimize
– Compile
• Relies on formalism
• Requires formal
• Specification (to allow transformations)

6. Phased Development: Increments and Iterations
• Shorter cycle time
• System delivered in pieces
– enables customers to have some functionality while the rest is being developed
• Allows two systems functioning in parallel
– the production system (release n): currently being used
– the development system (release n+1): the next version
• Incremental development: starts with small functional subsystem and adds functionality with each
new release
• Iterative development: starts with full system, then changes functionality of each subsystem with
each new release
Phased development is desirable for several reasons
– Training can begin early, even though some functions are missing
– Markets can be created early for functionality that has never before been offered
– Frequent releases allow developers to fix unanticipated problems globally and quickly
– The development team can focus on different areas of expertise with different releases

7. Spiral Model
• Suggested by Barry Boehm (1988)
• Combines development activities with risk management to minimize and control risks
• The model is presented as a spiral in which each iteration is represented by a circuit around four
major activities
– Plan
– Determine goals, alternatives and constraints
– Evaluate alternatives and risks
– Develop and test
Agile Methods
• Emphasis on flexibility in producing software quickly and capably
• Agile manifesto
– Value individuals and interactions over process and tools
– Prefer to invest time in producing working software rather than in producing comprehensive
documentation
– Focus on customer collaboration rather than contract negotiation
– Concentrate on responding to change rather than on creating a plan and then
following it

8. Agile Methods: Examples of Agile Process
• Extreme programming (XP)
• Crystal: a collection of approaches based on the notion that every project needs a unique
set of policies and conventions
• Scrum: 30-day iterations; multiple self-organizing teams; daily “scrum” coordination
• Adaptive software development (ASD)
Agile Methods: Extreme Programming
• Emphasis on four characteristics of agility
– Communication: continual interchange between customers and developers
– Simplicity: select the simplest design or implementation
– Courage: commitment to delivering functionality early and often
– Feedback: loops built into the various activities during the development process
Agile Methods: Twelve Facets of XP
• The planning game (customer defines value)
• Small release
• Metaphor (common vision, common names)
• Simple design
• Writing tests first
• Refactoring
• Pair programming
• Collective ownership
• Continuous integration (small increments)
• Sustainable pace (40 hours/week)
• On-site customer
• Coding standard
Sidebar 2.2 When Extreme is Too Extreme?
• Extreme programming's practices are interdependent
– A vulnerability if one of them is modified
• Requirements expressed as a set of test cases must be passed by the software
– System passes the tests but is not what the customer is paying for
• Refactoring issue
– Difficult to rework a system without degrading its architecture

9. Chapter 3
Objectives
• Tracking project progress
• Project personnel and organization
• Effort and schedule estimation
• Risk management
• Using process modeling with project planning
3.1 Tracking Progress
• Do we understand customer’s needs?
• Can we design a system to solve customer’s problems or satisfy customer’s needs?
• How long will it take to develop the system?
• How much will it cost to develop the system?
Project Schedule
• Describes the software-development cycle for a particular project by
– enumerating the phases or stages of the project
– breaking each phase into discrete tasks or activities to be completed
• Portrays the interactions among the activities and estimates the times that each task or activity will
take
Project Schedule: Approach
• Understanding customer’s needs by listing all project deliverables
– Documents
– Demonstrations of function
– Demonstrations of subsystems
– Demonstrations of accuracy
– Demonstrations of reliability, performance or security
• Determining milestones and activities to produce the deliverables
Milestones and activities
• Activity: takes place over a period of time
• Milestone: completion of an activity – a particular point in time
• Precursor: event or set of events that must occur in order for an activity to start
• Duration: length of time needed to complete an activity
• Due date: date by which an activity must be completed
• Project development can be separated into a succession of phases which are composed of steps,
which are composed of activities

10. Phases, Steps, and Activities in Building a House

11. Milestones in Building a House
Work Breakdown and Activity Graphs
• Work breakdown structure depicts the project as a set of discrete pieces of work
• Activity graphs depict the dependencies among activities
– Nodes: project milestones
– Lines: activities involved
Activity graph for building a house
Estimating Completion

12. • Adding estimated time in activity graph of each activity to be completed tells us more about the
project's schedule
Activity Graph
Estimating Completion for Building a House

13. Critical Path Method (CPM)
• Minimum amount of time it will take to complete a project
– Reveals those activities that are most critical to completing the project on time
• Real time (actual time): estimated amount of time required for the activity to be completed
• Available time: amount of time available in the schedule for the activity's completion
• Slack time: the difference between the available time and the real time for that activity
• Critical path: the slack at every node is zero
– can be more than one in a project schedule
• Slack time = available time – real time = latest start time – earliest start time
Slack Time for Activities of Building a House
CPM Bar Chart

14. • Including information about the early and late start dates
• Asterisks indicate the critical path
Tools to Track Progress
• Example: to track progress of building communication software
Tools to Track Progress: Gantt Chart

15. • Activities shown in parallel
– helps understand which activities can be performed concurrently
Tools to Track Progress: Resource Histogram
• Shows people assigned to the project and those needed for each stage of development
Tools to Track Progress: Expenditures Tracking

16. • An example of how expenditures can be monitored
3.2 Project Personnel
• Key activities requiring personnel
– requirements analysis
– system design
– program design
– program implementation
– testing
– training
– maintenance
– quality assurance
• There is great advantage in assigning different responsibilities to different people
Choosing Personnel
• Ability to perform work
• Interest in work
• Experience with
– Similar applications
– Similar tools, languages, or techniques
– Similar development environments
• Training
• Ability to communicate with others
• Ability to share responsibility
• Management skills
Communication

17. • A project's progress is affected by
– Degree of communication
– Ability of individuals to communicate their ideas
• Software failures can result from breakdown in communication and understanding
• Line of communication can grow quickly
• If there is n worker in project, then there are n(n-1)/2 pairs of communication
Sidebar 3.1 Make Meeting Enhance Project Progress
• Common complains about meeting
– the purpose is unclear
– the attendees are unprepared
– essential people are late or absent
– the conversation veers away from its purpose
– participants do not discuss, instead argue
– decisions are never enacted afterward
• Ways to ensure a productive meeting
– clearly decide who should be in the meeting
– develop an agenda
– have someone who tracks the discussion
– have someone who ensures follow-up actions

18. Work Styles
• Extroverts: tell their thoughts
• Introverts: ask for suggestions
• Intuitive: base decisions on feelings
• Rational: base decisions on facts, options
• Horizontal axis: communication styles
• Vertical axis: decision styles
• Work styles determine communication styles
• Understanding work styles
– help to be flexible
– give information based on other's priorities
• Impacts interaction among customers, developers and users
Project Organization
• Depends on
– backgrounds and work styles of team members
– number of people on team
– management styles of customers and developers
• Examples:
– Chief programmer team: one person totally responsible for a system's design and
development
– Egoless approach: hold everyone equally responsible
Project Organization: Chief Programmer Team

19. • Each team member must communicate often with chief, but not necessarily with other team
members
• Characteristics of projects and the suggested organizational structure to address them
Sidebar 3.2 Structure vs. Creativity
• Experiment by Sally Phillip examining two groups building a hotel
– Structured team: clearly defined responsibilities
– Unstructured team: no directions
• The results are always the same
– Structured teams finish a functional Days Inn
– Unstructured teams build a creative, multistoried Taj Mahal and never complete
• Good project management means finding a balance between structure and creativity
3.3 Effort Estimation
• Estimating project costs is one of the crucial aspects of project planning and management
• Estimating cost has to be done as early as possible during the project life cycle
• Type of costs
– facilities: hardware, space, furniture, telephone, etc
– software tools for designing software
– staff (effort): the biggest component of cost
Estimation should be Done Repeatedly

20. • Uncertainty early in the project can affect the accuracy of cost and size estimations
Sidebar 3.3 Causes of Inaccurate Estimates
• Key causes
– Frequent request for change by users
– Overlooked tasks
– User's lack of understanding of the requirements
– Insufficient analysis when developing estimates
– Lack of coordination of system development, technical services, operations, data administration,
and other functions during development
– Lack of an adequate method or guidelines for estimating
• Key influences
– Complexity of the proposed application system
– Required integration with existing system
– Complexity of the program in the system
– Size of the system expressed as number of functions or programs
– Capabilities of the project team members
– Project team's experience with the application, the programming language, and hardware
– Capabilities of the project team members
– Database management system
– Number of project team member
– Extent of programming and documentation standards

21. Type of Estimation Methods
• Expert judgment
• Top-down or bottom-up
– Analogy: pessimistic (x), optimistic (y), most likely (z); estimate as (x + 4y + z)/6
– Delphi technique: based on the average of “secret” expert judgments
• Algorithmic methods: E = (a + bSc) m(X)
– Walston and Felix model: E = 5.25 S 0.91
– Bailey and Basili model: E = 5.5 + 0.73 S1.16
Expert Judgement: Wolverton Model
• Two factors that affect difficulty
– whether problem is old (O) or new (N)
– whether it is easy (E) or moderate (M)
Algorithmic Method: Watson and Felix Model
• A productivity index is included in the equation
• There are 29 factors that can affect productivity
– 1 if increase the productivity
– 0 if decrease the productivity
Algorithmic Method: Bailey-Basili technique
• Minimize standard error estimate to produce an equation such as E = 5.5 + 0.73S1.16
• Adjust initial estimate based on the difference ratio
– If R is the ratio between the actual effort, E, and the predicted effort, E’, then the effort
adjustment is defined as
– ERadj = R – 1 if R > 1
= 1 – 1/R if R < 1
• Adjust the initial effort estimate Eadj

22. – Eadj = (1 + ERadj)E if R > 1
= E/(1 + ERadj) if R < 1
Algorithmic Method: Bailey-Basili Modifier
3.3 Effort Estimation
COCOMO II: Stages of Development
• Application composition
– Prototyping to resolve high-risk user interface issues
– Size estimates in object points
• Early design
– To explore alternative architectures and concepts
– Size estimates in function points
• Postarchitecture
– Development has begun
– Size estimates in lines of code
COCOMO II: Estimate Application Points
• To compute application points, first we need to count the number of screens, reports and

23. programming language used to determine the complexity level
• Determine the relative effort required to implement a report or screen simple, medium or difficult
• Calculate the productivity factor based on developer experience and capability
• Determine the adjustment factors expressed as multipliers based on rating of the project
Complexity Weights for Application Points
Productivity Estimate Calculation
Tool Use Categories
Machine Learning Techniques
• Example: case-based reasoning (CBR)
– user identifies new problem as a case
– system retrieves similar cases from repository
– system reuses knowledge from previous cases
– system suggests solution for new case
• Example: neural network
– cause-effect network “trained” with data from past history
Machine learning techniques: Neural Network
• Neural network used by Sheppard to produce effort estimation

24. Machine Learning Techniques: CBR
• Involves four steps
– the user identifies a new problem as a case
– the system retrieves similar case from a repository of historical information
– the system reuses knowledge from previous case
– the system suggests a solution for the new case
• Two big hurdles in creating successful CBR system
– characterizing cases
– determining similarity
Finding the Model for Your Situation
• Mean magnitude of relative error (MMRE)
– absolute value of mean of [(actual - estimate)/ actual]
– goal: should be .25 or less
• Pred(x/100): percentage of projects for which estimate is within x% of the actual
– goal: should be .75 or greater for x = .25
– 75% project estimates are within 25% of actual
Evaluating Models (continued)

25. • No model appears to have captured the essential characteristics and their relationships for all types
of development
• It is important to understand which types of effort are needed during development even when we
have reasonably accurate estimate
– Categorize and save the results
• Two different reports of effort distribution from different researchers
3.4 Risk Management
What is a Risk?
• Risk is an unwanted event that has negative consequences
• Distinguish risks from other project events
– Risk impact: the loss associated with the event
– Risk probability: the likelihood that the event will occur
• Quantify the effect of risks
– Risk exposure = (risk probability) x (risk impact)
• Risk sources: generic and project-specific

26. Risk Management Activities
• Example of risk exposure calculation
PU: prob. of unwanted outcome
LU: lost assoc with unwanted outcome
• Three strategies for risk reduction
– Avoiding the risk: change requirements for performance or functionality

27. – Transferring the risk: transfer to other system, or buy insurance
– Assuming the risk: accept and control it
• Cost of reducing risk
– Risk leverage = (risk exposure before reduction – (risk exposure after reduction) / (cost
of risk reduction)
Sidebar 3.4 Boehm’s Top Ten Risk Items
• Personnel shortfalls
• Unrealistic schedules and budgets
• Developing the wrong functions
• Developing the wrong user interfaces
• Gold-plating
• Continuing stream of requirements changes
• Shortfalls in externally-performed tasks
• Shortfalls in externally-furnished components
• Real-time performance shortfalls
• Straining computer science capabilities
3.5 Project Plan
Project Plan Contents
• Project scope
• Project schedule
• Project team organization
• Technical description of system
• Project standards and procedures
• Quality assurance plan
• Configuration management plan
• Documentation plan
• Data management plan
• Resource management plan
• Test plan
• Training plan
• Security plan
• Risk management plan

28. • Maintenance plan
Project Plan Lists
• List of the people in development team
• List of hardware and software
• Standards and methods, such as
– algorithms
– tools
– review or inspection techniques
– design language or representations
– coding languages
– testing techniques
3.6 Process Models and Project Management
Enrollment Management Model: Digital Alpha AXP
• Establish an appropriately large shared vision
• Delegate completely and elicit specific commitments from participants
• Inspect vigorously and provide supportive feedback
• Acknowledge every advance and learn as the program progresses
• Vision: to “enroll” the related programs, so they all shared common goals
• An organization that allowed technical focus and project focus to contribute to the overall program

29. Accountability modeling: Lockheed Martin
• Matrix organization
– Each engineer belongs to a functional unit based on type of skill
• Integrated product development team
– Combines people from different functional units into interdisciplinary work unit
• Each activity tracked using cost estimation, critical path analysis, schedule tracking
– Earned value a common measure for progress
Accountability model used in F-16 Project

30. • Teams had multiple, overlapping activities
• An activity map used to illustrate progress on each activity
• Each activity’s progress was tracked using earned value chart
Anchoring (Common) Milestones

31. • Life cycle objectives
• Objectives: Why is the system being developed?
• Milestones and schedules: What will be done by when?
• Responsibilities: Who is responsible for a function?
• Approach: How will the job be done, technically and managerially?
• Resources: How much of each resource is needed?
• Feasibility: Can this be done, and is there a good business reason for doing it?
• Life-cycle architecture: define the system and software architectures and address architectural
choices and risks
• Initial operational capability: readiness of software, deployment site, user training
• The Win-Win spiral model suggested by Boehm is used as supplement to the milestones
3.7 Information System Example
Piccadilly System
• Using COCOMO II
• Three screens and one report
– Booking screen: complexity simple, weight 1
– Ratecard screen: complexity simple, weigth 1
– Availability screen: complexity medium, weight 2
– Sales report: complexity medium, weight 5

32. • Estimated effort = 182 person-month
3.8 Real Time Example
Ariane-5 System
• The Ariane-5 destruction might have been prevented had the project managers developed a risk
management plan
– Risk identification: possible problem with reuse of the Ariane-4)
– Risk exposure: prioritization would have identified if the inertial reference system (SRI) did
not work as planned
– Risk control: assessment of the risk using reuse software
– Risk avoidance: using SRI with two different designs

33. Chapter 4 - Capturing the Requirements
Objectives
• Eliciting requirements from the customers
• Modeling requirements
• Reviewing requirements to ensure their quality
• Documenting requirements for use by the design and test teams
4.1 The Requirements Process
• A requirement is an expression of desired behavior
• A requirement deals with
– objects or entities
– the state they can be in
– functions that are performed to change states or object characteristics
• Requirements focus on the customer needs, not on the solution or implementation
– designate what behavior, without saying how that behavior will be realized
Sidebar 4.1 Why Are Requirements Important?
• Top factors that caused project to fail
– Incomplete requirements
– Lack of user involvement
– Unrealistic expectations
– Lack of executive support
– Changing requirements and specifications
– Lack of planning
– System no longer needed
• Some part of the requirements process is involved in almost all of these causes
• Requirements error can be expensive if not detected early
Process for Capturing Requirements
• Performed by the req. analyst or system analyst
• The final outcome is a Software Requirements Specification (SRS) document

34. Sidebar 4.2 Agile Requirements Modeling
• If requirements are tightly coupled and complex, we may be better off with a “heavy” process that
emphasizes up-front modeling
• If the requirements are uncertain, agile methods are an alternative approach
• Agile methods gather and implement the requirements in increments
• Extreme Programming (XP) is an agile process
– The requirements are defined as we build the system
– No planning or designing for possible future requirements
– Encodes the requirements as test cases that eventually implementation must pass
4.2 Requirements Elicitation
• Customers do not always understand what their needs and problems are
• It is important to discuss the requirements with everyone who has a stake in the system
• Come up with agreement on what the requirements are
– If we cannot agree on what the requirements are, then the project is doomed to fail
Stakeholders
• Clients: pay for the software to be developed
• Customers: buy the software after it is developed
• Users: use the system
• Domain experts: familiar with the problem that the software must automate
• Market Researchers: conduct surveys to determine future trends and potential customers

35. • Lawyers or auditors: familiar with government, safety, or legal requirements • Software engineers
or other technology experts
Sidebar 4.3 Using Viewpoints to Manage Inconsistency
• No need to resolve inconsistencies early in the requirements process (Easterbrook and Nuseibeh,
1996)
• Stakeholders' views documented and maintained as separate Viewpoints through the software
development process
– The requirements analyst defines consistency rules that should apply between Viewpoints
– The Viewpoints are analyzed to see if they conform to the consistency requirements
• Inconsistencies are highlighted but not addressed until there is sufficient information to make
informed decision
Means of Eliciting Requirements
• Interviewing stake holders
• Reviewing available documentations
• Observing the current system (if one exists)
• Apprenticing with users to learn about user's task in more details
• Interviewing user or stakeholders in groups
• Using domain specific strategies, such as Joint Application Design, or PIECES
• Brainstorming with current and potential users
• The Volere requirements process model suggests some additional sources for requirements

36. 4.3 Types of Requirements
• Functional requirement: describes required behavior in terms of required activities
• Quality requirement or nonfunctional requirement: describes some quality characteristic that the
software must posses
• Design constraint: a design decision such as choice of platform or interface components
• Process constraint: a restriction on the techniques or resources that can be used to build the
system
Sidebar 4.4 Making Requirements Testable
• Fit criteria form objective standards for judging whether a proposed solution satisfies the
requirements
– It is easy to set fit criteria for quantifiable requirements
– It is hard for subjective quality requirements
• Three ways to help make requirements testable
– Specify a quantitive description for each adverb and adjective
– Replace pronouns with specific names of entities
– Make sure that every noun is defined in exactly one place in the requirements documents
Resolving Conflicts
• Different stakeholder has different set of requirements
– potential conflicting ideas
• Need to prioritize requirements
• Prioritization might separate requirements into three categories
– essential: absolutely must be met
– desirable: highly desirable but not necessary
– optional: possible but could be eliminated
Two Kinds of Requirements Documents
• Requirements definition: a complete listing of everything the customer wants to achieve
– Describing the entities in the environment where the system will be installed
• Requirements specification: restates the requirements as a specification of how the proposed
system shall behave
• Requirements defined anywhere within the environment's domain, including the system's interface
• Specification restricted only to the intersection between environment and system domain

37. 4.4 Characteristics of Requirements
• Correct
• Consistent
• Unambiguous
• Complete
• Feasible
• Relevant
• Testable
• Traceable
4.5 Modeling Notations
• It is important to have standard notations for Modeling, documenting, and communicating decisions
• Modeling helps us to understand requirements thoroughly
– Holes in the models reveal unknown or ambiguous behavior
– Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements
Entity-Relationship Diagrams
• A popular graphical notational paradigm for representing conceptual models
• Has three core constructs
– An entity: depicted as a rectangle, represents a collection of real-world objects that have common
properties and behaviors
– A relationship: depicted as an edge between two entities, with diamond in the middle of the edge
specifying the type of relationship
– An attribute: an annotation on an entity that describes data or properties associated with the entity

38. Entity diagram of turnstile problem
• ER diagrams are popular because
– they provide an overview of the problem to be addressed
– the view is relatively stable when changes are made to the problem's requirements
• ER diagram is likely to be used to model a problem early in the requirements process
ER Diagrams Example: UML Class Diagram
• UML (Unified Modeling Language) is a collection of notations used to document software
specifications and designs
• It represents a system in terms of
– objects: akin to entities, organized in classes that have an inheritance hierarchy
– methods: actions on the object's variables
• The class diagram is the flagship model in any UML specification
– A sophisticated ER diagram relating the classes (entities) in the specification
UML Class Diagram of Library Problem

39. • Attributes and operations are associated with the class rather than instances of the class
• A class-scope attribute represented as an underlined attribute, is a data value that is shared by all
instances of the class
• A class-scope operation written as underlined operation, is an operation performed by the abstract
class rather than by class instances
• An association, marked as a line between two classes, indicates a relationship between classes'
entities
• Aggregate association is an association that represents interaction, or events that involve objects in
the associated (marked with white diamond)
– “has-a” relationship
• Composition association is a special type of aggregation, in which instances of the compound class
are physically constructed from instances of component classes (marked with black diamond)
Event Traces
• A graphical description of a sequence of events that are exchanged between real-world entities
– Vertical line: the timeline of distinct entity, whose name appear at the top of the line
– Horizontal line: an event or interaction between the two entities bounding the line
– Time progresses from top to bottom
• Each graph depicts a single trace, representing one of several possible behaviors
• Traces have a semantic that is relatively precise, simple and easy to understand
Graphical representation of two traces for the turnstile problem
– trace on the left represents typical behavior
– trace on the right shows exceptional behavior
Event Traces Example: Message Sequence Chart

40. • An enhanced event-trace notation, with facilities for creating and destroying entities, specifying
actions and timers, and composing traces
– Vertical line represents a participating entity
– A message is depicted as an arrow from the sending entity to the receiving entity
– Actions are specified as labeled rectangles positioned on an entity's execution line
– Conditions are important states in an entity's evolution, represented as labeled hexagon
• Message sequence chart for library loan transaction
State Machines
• A graphical description of all dialog between the system and its environment
– Node (state) represents a stable set of conditions that exists between event occurrences
– Edge (transition) represents a change in behavior or condition due to the occurrence of an event
• Useful both for specifying dynamic behavior and for describing how behavior should change in
response to the history of events that have already occurred
• Finite state machine model of the turnstile problem

41. • A path: starting from the machine's initial state and following transitions from state to state
– A trace of observable events in the environment
• Deterministic state machine: for every state and event there is a unique response
State Machines Example: UML State chart Diagrams
• A UML state chart diagram depicts the dynamic behavior of the objects in a UML Class
– UML class diagram has no information about how the entities behave, how the behaviors change
• A UML model is a collection of concurrently executing state charts
• UML state chart diagram have a rich syntax, including state hierarchy, concurrency, and
intermachine communication
• State hierarchy is used to unclutter diagrams by collecting into superstate those states with
common transitions
• A superstate can actually comprise multiple concurrent submachines, separated by dashed line
– The submachines are said to operate concurrently
The UML statechart diagram for the Publication class from the Library class model
• An equivalent statechart for Publication class that does not make use of state hierarchy or
concurrency
– comparatively messy and repetitive

42. • The UML statechart diagram for Loan association class illustrates how states can be annotated
with local variables, actions and activities
State Machines: Ways of Thinking about State
• Equivalence classes of possible future behavior
• Periods of time between consecutive events
• Named control points in an object's evolution
• Partition of an object's behavior
State Machines Example: Petri Nets
• A form or state-transition notation that is used to model concurrent activities and their interaction
– Circles (places) represent activities or conditions
– Bars represents transitions
– Arcs connect a transition with its input places and its ouput places
– The places are populated with tokens, which act as enabling conditions for the transitions
– Each arc can be assigned a weight that specifies how many tokens are removed from arc's input
place, when the transition fires
• Petri net of book loan
• A high level Petri net specification for the library problem

43. Data-Flow Diagrams
• ER diagram, event trace, state machines depict only lower-level behaviors
• A data-flow diagram (DFD) models functionality and the flow of data from one function to another
– A bublbe represents a process
– An arrow represents data flow
– A data store: a formal repository or database of information
– Rectangles represent actors: entities that provide input data or receive the output result
• A high-level data-flow diagram for the library problem
• Advantage:

44. – Provides an intuitive model of a proposed system's high-level functionality and of the data
dependencies among various processes
• Disadvantage:
– Can be aggravatingly ambiguous to a software developer who is less familiar with the problem
being modeled
Data-Flow Diagrams Example: Use Cases
• Components
– A large box: system boundary
– Stick figures outside the box: actors, both human and systems
– Each oval inside the box: a use case that represents some major required functionality and its
variant
– A line between an actor and use case: the actor participates in the use case
• Use cases do not model all the tasks, instead they are used to specify user views of essential
system behavior
• Library use cases including borrowing a book, returning a borrowed book, and paying a library fine
Functions and Relations
• Formal methods or approach: mathematically based specification and design techniques
• Formal methods model requirements or software behavior as a collection of mathematical functions
or relations
– Functions specify the state of the system's execution, and output
– A relation is used whenever an input value maps more than one output value
• Functional method is consistent and complete
• Example: representing turnstile problem using two functions
– One function to keep track of the state
– One function to specify the turnstile output

45. Functions and Relations Example: Decision Tables
• It is a tabular representation of a functional specification that maps events and conditions to
appropriate responses or action
• The specification is formal because the inputs (events and conditions) and outputs (actions) may
be expressed in natural language
• If there are n input conditions, there are 2n possible combinations of input conditions
• Combinations map to the same set of result can be combined into a single column
• Decision table for library functions borrow, return, reserve, and unreserved
Functions and Relations Example: Parnas Tables
• Tabular representations of mathematical functions or relations
– The column and row headers are predicates used to specify cases
– The internal table entries store the possible function results
– An entry “X” either could be invalid under the specified conditions or the combination of conditions
is infeasible
Calc due date (patron, publication, event, Today) =

46. Logic
• An operational notation is a notation used to describe a problem or a proposed software solution in
terms of situational behavior
– Model of case-based behavior
– Examples: state machine, event traces, data-flow diagram, functional method
• A descriptive notation is a notation that describes a problem or a proposed solution in terms of its
properties or its variant
– Example: logic
• A logic consists of a language for expressing properties and a set of inference rules for deriving
new, consequent properties from the stated properties
• In logic, a property specification represents only those values of the property's variables for which
the property's expression evaluates to true
• It is first-order logic, comprising typed variables, constants, functions, and predicates
• Consider the following variables of turnstile problem, with their initial value
• The first-order logic expressions
• Temporal logic introduces additional logical connectives for constraining how variables can change
value over time
• The following connectives constrain future variable values, over a single execution
– □f Ξ f is true now and throughout the rest of execution
– ⋄f Ξ f is true now or at some point in the execution

47. – ○f Ξ f is true in the next point in the execution
– f W g = f is true until a point where g is true, but g may never be true
• Turnstile properties expressed in temporal logic
□ (insert_coin => ○ (may_enter W push))
□ (∀n(insert_coin ∧ num_coins=n) => ○(num_coins=n+1))
Logic Example: Object Constrain Language (OCL)
• A constrain language that is both mathematically precise and easy for non-mathematicians to read,
write, and understand
• Designed for expressing constrains on object models, and expressing queries on object type
Library classes annotated with OCL properties
Logic Example: Z
• A formal requirements-specification language that
– structures set-theoretic definitions of variables into a complete abstract-data-type model of problem
– uses logic to express the pre- and postconditions for each operation
• Method of abstractions are used to decompose a specification into manageable sized modules,
called schemas

48. Partial Z specification for the library problem
Algebraic Specifications
• To specify the behavior of operations by specifying interactions between pairs of operations rather
than modeling individual operations
• It is hard to define a set of axioms that is complete and consistent and that reflects the desired
behavior
Algebraic Specifications Example: SDL Data
• Partial SDL data specification for the library problem

49. 4.6 Requirements and Specification Languages
Unified Modeling Language (UML)
• Combines multiple notation paradigms
• Eight graphical modeling notations, and the OCL constrain language, including
– Use-case diagram (a high-level DFD)
– Class diagram (an ER diagram)
– Sequence diagram (an event trace)
– Collaboration diagram (an event trace)
– Statechart diagram (a state-machine model)
– OCL properties (logic)
Specification and Description Language (SDL)
• Standardized by the International Telecommunication Union
• Specifies the behavior of real-time, concurrent, distributed processes that communicate with each
other via unbounded message queues
• Comprises
– SDL system diagram (a DFD)
– SDL block diagram (a DFD)
– SDL process diagram (a state-machine model)
– SDL data type (algebraic specification)
• Often accompanied by a set of Message Sequence Chart (MSC)

50. SDL System Diagram
• The top-level blocks of the specification and communication channels that connect the blocks
• Channels are directional and are labeled with the type of signals
• Message is asynchronous
SDL Block Diagram
• SDL block diagram Models a lower-level collection of blocks and the message-delaying channels
that interconnect them
• Figure depicts a collection of lowest-level processes that communicate via signal routes
• Signal routes pass messages synchronously
SDL Process Diagram
• It is a state-machine whose transitions are sequences of language constructs (input, decisions,
tasks, outputs) that start and end at state constructs

51. Software Cost Reduction (SCR)
• Collection of techniques that were designed to encourage software developers to employ good
software-engineering design principles
• Models software requirements as a mathematical function, REQ, that maps monitored variables to
controlled variables
– monitored variables: environmental variables that are sensed by the system
– controlled variables: environmental variables that are set by the system
• The function REQ is decomposed into a collection of tabular functions
• REQ is the result of composing the tabular functions into network (a DFD) as shown in the picture.
• Edges reflect the data dependencies among the functions
• Execution steps start with a change in the value of one monitored variable, then propagate through
the network, in a single synchronized step
Other Features of Requirement Notations
• Some techniques include notations
– for the degree of uncertainty or risk with each requirement
– for tracing requirements to other system documents such as design or code, or to other systems,
such as when requirements are reused
• Most specification techniques have been automated to some degree
4.7 Prototyping Requirements
Building a Prototype

52. • To elicit the details of proposed system
• To solicit feedback from potential users about
– what aspects they would like to see improve
– which features are not so useful
– what functionality is missing
• Determine whether the customer's problem has a feasible solution
• Assist in exploring options for optimizing quality requirements
Prototyping Example
• Prototype for building a tool to track how much a user exercises each day
• Graphical representation of first prototype, in which the user must type the day, month and year
• Second prototype shows a more interesting and sophisticated interface involving a calendar
– User uses a mouse to select the month and year
– The system displays the chart for that month, and the user selects the appropriate date in the chart
• Third prototype shows that instead of calendar, the user is presented with three slide bars
– User uses the mouse to slide each bar left or right
– The box at the bottom of the screen changes to show the selected day, month, and year

53. Approaches to Prototyping
• Throwaway approach
– Developed to learn more about a problem or a proposed solution, and that is never intended to be
part of the delivered software
– Allow us to write “quick-and-dirty”
• Evolutionary approach
– Developed not only to help us answer questions but also to be incorporated into the final product
– Prototype has to eventually exhibit the quality requirements of the final product, and these qualities
cannot be retrofitted
• Both techniques are sometimes called rapid prototyping
Prototyping vs. Modeling
• Prototyping
– Good for answering questions about the user interfaces
• Modeling
– Quickly answer questions about constraints on the order in which events should occur, or about
the synchronization of activities
4.8 Requirements Documentation
Requirement Definition: Steps Documenting Process
• Outline the general purpose and scope of the system, including relevant benefits, objectives, and
goals
• Describe the background and the rationale behind proposal for new system
• Describe the essential characteristics of an acceptable solution
• Describe the environment in which the system will operate
• Outline a description of the proposal, if the customer has a proposal for solving the problem
• List any assumptions we make about how the environment behaves
Requirements Specification: Steps Documenting Process
• Describe all inputs and outputs in detail, including
– the sources of inputs

54. – the destinations of ouputs,
– the value ranges
– data format of inputs and output data
– data protocols
– window formats and organizations
– timing constraint
• Restate the required functionality in terms of the interfaces' inputs and outputs
• Devise fit criteria for each of the customer's quality requirements
Sidebar 4.6 Level of Specification
• Survey shows that one of the problems with requirement specifications was the uneven level of
specification
– Different writing sytles
– Difference in experience
– Different formats
– Overspecifying requirements
– Underspecifying requirements
• Recommendations to reduce unevenness
– Write each clause so that it contains only one requirement
– Avoid having one requirement refer to another requirement
– Collect similar requirements together
Sidebar 4.7 Hidden Assumptions
• Two types of environmental behavior of interest
– desired behavior to be realized by the proposed system
– existing behavior that is unchanged by the proposed system
• often called assumptions or domain knowledge
• Most requirements writers consider assumptions to be simply the conditions under which the
system is guaranteed to operate correctly
IEEE Standard for SRS Organized by Objects
1. Intodruction to the Document
1.1 Purpose of the Product
1.2 Scope of the Product
1.3 Acronyms, Abbreviations, Definitions
1.4 References

55. 1.5 Outline of the rest of the SRS
2. General Description of Product
2.1 Context of Product
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.2 Class 2
…
3.3 Performance Requirements
3.4 Design Constraints
3.5 Quality Requirements
3.6 Other Requirements
4. Appendices
Process Management and Requirements Traceability
• Process management is a set of procedures that track
– the requirements that define what the system should do
– the design modules that are generated from the requirement
– the program code that implements the design
– the tests that verify the functionality of the system
– the documents that describe the system
• It provides the threads that tie the system parts together
Development Activities
• Horizontal threads show the coordination between development activities

56. 4.9 Validation and Verification
• In requirements validation, we check that our requirements definition accurately reflects the
customer's needs
• In verification, we check that one document or artifact conforms to another
• Verification ensures that we build the system right, whereas validation ensures that we build the
right system
List of techniques to validate requirements

57. Requirements Review
• Review the stated goals and objectives of the system
• Compare the requirements with the goals and objectives
• Review the environment in which the system is to operate
• Review the information flow and proposed functions
• Assess and document the risk, discuss and compare alternatives
• Testing the system: how the requirements will be revalidated as the requirements grow and change
Sidebar 4.8 Number of Requirements Faults
• Jone and Thayes's studies show that
– 35% of the faults to design activities for project of 30,000-35,000 delivered source instructions
– 10% of the faults to requirements activities and 55% of the faults to design activities for projects of
40,000-80,000 delivered source instructions
– 8% to 10% of the faults to requirements activities and 40% to 55% of the faults to design activities
for project of 65,000-85,000 delivered source instructions
• Basili and Perricone report
– 48% of the faults observed in a medium-scale software project were attribute to “incorrect or
misinterpreted functional specification or requirements”
• Beizer attributes 8.12% of the faults in his samples to problems in functional requirements
Verification
• Check that the requirements-specification document corresponds to the requirements definition
• Make sure that if we implement a system that meets the specification, then the system will satisfy
the customer's requirements
• Ensure that each requirement in the definition document is traceable to the specification
Sidebar 4.9 Computer-Aided Verification

58. • Model checking is an exhaustive search for a specification's execution space, to determine whether
some temporal-logic property holds of the execution
– Atlee (1996) used the SMV model checker to verify five properties of an SCR specification of the
A-7 naval aircraft
• A theorem prover uses a collection of built-in theories, inference rules, and decision procedures for
determining whether a set of asserted facts logically entails some unasserted fact
– Dutertre and Stavridou (1997) used theorem prover PVS to verify some of the functional and
safety requirements of an avionic system
4.10 Measuring Requirements
• Measurements focus on three areas
– product
– process
– resources
• Number of requirements can give us a sense of the size of the developed system
• Number of changes to requirements
– Many changes indicate some instability or uncertainty in our understanding of the system
• Requirement-size and change measurements should be recorded by requirements type
Rating Scheme on Scale from 1 to 5
1. You understand this requirement completely, have designed systems from similar requirements,
and have no trouble developing a design from this requirement
2. Some elements of this requirement are new, but they are not radically different from requirements
that have been successfully designed in the past
3. Some elements of this requirement are very different from requirements in the past, but you
understand the requirement and can develop a good design from it
4. You cannot understand some parts of this requirement, and are not sure that you can develop a
good design
5. You do not understand this requirement at all, and cannot develop a design
Testers/Designers Profiles
• Figure (a) shows profiles with mostly 1s and 2s
– The requirements are in good shape
• Figure (b) shows profiles with mostly 4s and 5s
– The requirements should be revised

59. 4.11 Choosing a Specification Technique
Criteria for Evaluating Specification Methods
• Applicability
• Implementability
• Testability/Simulation
• Checkability
• Maintainability
• Modularity
• Level of abstraction
• Soundness
• Veriability
• Run time safety
• Tools maturity
• Looseness
• Learning curve
• Technique maturity
• Data modeling
• Discipline
Steps
• Determine which of the criteria are especially important
• Evaluate each of the candidate techniques with respect to the criteria
• Choose a specification technique that best supports the criteria that are most important to the
problem

60. Important of Specification Criteria During Reactive- System Life Cycle
• R=Requirements, D=Design, I=Implementation, T=Testing, M=Maintenance, O=Other
Picadilly Television System
• High-level diagram captures the essential functionality
– Shows nothing about the ways in which each of these use cases might succeed or fail

61. Picadilly Television System: Message Sequence Chart
Picadilly Television System: Partial UML Class Diagram

62. 4.13 Real-Time Example
• Ariane-5 failed due to requirement validation not done properly
– Requirements validation could have played a crucial role in preventing the rocket's explosion
• Two criteria that are especially important for specifying a system such as Ariane-5
– Testability/simulation and runtime safety
– SDL was rated “strong” for testability/simulation and runtime safety
SDL Model
• SDL model for coin slot process that consists of several concurrent communicating process