1. PART II EMERGING SOFTWARE ENGINEERING PLUS REQUIREMENTS & DESIGN

2. EMERGING SOFTWARE PROCESS & METHODOLOGIES

3. CHAPTER 5

4. Problems with “Traditional” Processes
Focused on and oriented towards “large projects” and lengthy development time (years) — started SWE.
Inability to cope with changes in requirements and technology fast enough — “formal” change mgmt.
Assumes requirements are completely understood at beginning of project — stable requirements.
Starting to rely on “non-sustainable” heroic and lengthy development effort by the developers — hard to maintain “constantly high” productivity.
Complex set of activities — needed process experts.
Waste or duplication of effort, especially in documentation — formal documentation needed for long and large project communications.

5. More Recent Processes: Agile Methodologies
Family of software development methodologies:
“Short” releases and multiple iterations
Incremental design/development
User involvement (especially for in-house)
Minimal documentation
Informal communications
Assumes changes

6. The Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it.
That is, while there is value in the items on the “right,” we value the items on the “left” more.”
“left” “right”
1. Individuals and interactions - - over processes and tools 2. Working software - - over comprehensive documentation 3. Customer collaboration - - over contract negotiation 4. Responding to change - - over following a plan — “dogmatically”

7. Some Agile Methodologies
Extreme Programming (XP) – the first by Kent Beck (1990s)
Crystal Clear/Orange – by Alister Cockburn
Scrum – currently popular
(not really part of Agile – partially agile)
RUP (rational unified process)
Microsoft Solutions Framework (tool/process)

8. XP’s Core Values Communication (between team and with customers)
Simplicity (in design and code - KIS principle)
Feedback (at many levels)
Courage (to make and implement difficult decision)

9. Extreme Programming (XP)
XP Design
Follows the KIS principle
For difficult design problems, suggests the creation of “spike solutions”—a design prototype
Encourages “refactoring”—an iterative refinement of the internal program design
XP Coding
Recommends the construction of a unit test for a store before coding commences
Encourages “pair programming”
XP Testing
All unit tests are executed daily
“Acceptance tests” are defined by the customer and executed to assess customer visible functionality

10. Core Software Engineering Principles
Provide value to the customer and the user
KIS—keep it simple! but not any simpler
Maintain the product and project “vision”
What you produce, others will consume
Be open to the future consider “what if’s”
Plan ahead for reuse but beware of general solutions.
Think! before you take any action!

11. XP’s Fundamental Principles
Rapid feedback
Simplicity
Incremental change
Embrace change
Quality work
Directly from “core” values

12. XP’s Lesser/Other Principles
Ongoing learning
Small initial investment
Playing to win
Concrete experiments
Open, honest communications
Working with people’s instincts
Accepting responsibility
Local adaptation
Traveling light
Honest measurement

13. (READ AT HOME) XP’s 12 Key Practices
Based on the concept of quick and constant “feedback mechanism” involving:
Planning Game (small units of requirements)
Onsite Customer (immediate and better feedback)
Metaphor (use one set of metaphor for design/architecture)
Simple Design (just enough to cover what’s needed)
Coding Standard (facilitates better communication)
Collective Code Ownership (peer pressure to improve code)
Pair Programming (feedback and shared improvements)
Refactoring (continuous examination for duplicative design/code)
Continuous Functional and Unit Testing (100% completion)
Small/Short Releases
Continuous Integration (integrating of small releases)
40 Hour Work (high morale and energy level)
some
recognition of
“human”
aspects

14. Crystal (proposed by Cockburn & Highsmith)
Crystal—distinguishing features
Actually a family of process models that allow “maneuverability” based on problem characteristics
Face-to-face communication is emphasized
Suggests the use of “reflection workshops” to review the work habits of the team
Classified projects via:
Size (by number of developers involved)
Criticality (by losses a malfunction or defect will cause – “quality”)
Priority (time pressure on the project)
Introduced a family of 3 methodologies
Crystal Clear for “non-critical” projects (6–8 people)
Crystal Orange for “critical” projects (up to 40 people)
Crystal Orange Web for web development

15. Scrum Development Process (Currently Popular)
First introduced by Takeuchi and Nonaka (Japan) in 1986 modeled after the way rugby game is played.
Ken Schwaber and Mike Beedle published a book, “Agile Software Development with Scrum,” in 2001.
It is an incremental and iterative development approach:
Develops small “sprints,” or increments (of features) in a short cycle of about 2–3 weeks. Work is partitioned into “packets”.
Meetings are very short and sometimes conducted without chairs.
Demos are delivered to the customer with a time-box allocated.
There are three main roles.
Product Owner who talks to and decides with users about the content of each sprint
Scrum Master who runs the sprints
Scrum Team of about 7–8 members who develop the sprint

16. DO HERE PROBLEM 2: SOFTWARE COST EVALUATION USING THE
4-STEPS “LINEAR MODEL.
PROBLEM 3: COST OF MODULARITY

17. PROBLEM 2. A contractor has incurred in an overrun in the amount of $K 1960 representing 70% of the project’s total overrun. The rest of the overrun is charged to the main office. This is a project delivered on exactly 30 months (it could not accept delays due to a very tight window for the delivery). ANS:
(i) Calculate the total distribution of time used per each of the 4 stages. Separate the contractor and the main office times.
(ii) Assuming the given overrun distribution between the main office and the contractor calculate the overrun of each party and also the total overrun of the project.
(iii) Assuming that the overall project was overrun by 35%, calculate the value of the initial project and the total final cost for this project.
(iv) Given that the contractor was assigned to do 60% of the total initial project, how much was the contractor's real overrun (in %) when using his real budget money base?
(v) Use the 4-step waterfall model calculate how much total money was spent at each stage assuming that the first two stages were done by the main office.
(vi) Assume that the average employee salary at the main office was $K 90 and $K 110 at the contractor's. Calculate the cost per employee if the main office's burden is 150% (2.50) and the contractor's is 180% (2.80).

18. (i) requirements 24% 7.2 [2pts] design 16% 4.8 [2pts]
ANSWER TO PROBLEM 2:
Stage Months
(i) requirements 24% [2pts]
design 16% [2pts]
coding 12% [2pts]
testing 48% [2pts]
TOTAL TIME
Main Office total time = = 12.0 months [2pts]
Contractor to total time = = 18.0 months [2pts]
ii) A= 30% B=70%,
Overrun of Contractor (B=70%) = $K 1,960 [2pts]
Overrun Main Office (A=30%) = 1960*3/7 = $K 840 [2pts]
Project Total overrun = = $K 2,800 [2pts]
iii) Total Overrun =$M 28 (= 35%)
Initial Project Value = 28/.35 = = $K 8,000 [2pts]
Total Project Cost = = $K 10,800 [2pts]
iv) Initial contractor budget (=60%) = 80*0.6 = $K 4,800 [2pts]
Actual contractor overrun = 1960/ = % [2pts]
Budget for the Main Office (=40%) = 8000*0.4 = $K 3200 [no point]

19. v) Total main office’s cost = 0.4*8000 + 840 = $K 4,040
Total contractor’s cost = 0.6* = $K 6,760
Total project cost = $K 10, 800.
requirements 24% = $K 2,592 [2pts] 60% 2,424 [2pts]+1
design 16% = $K 1,728 [2pts] 40% 1,616 [2pts]+1
Total main office 40% = $K 4,320 [no point] 4,040 [no point]
coding 12% = $K 1,296 [2pts] 20% 1,352 [2pts]+1
testing 48% = $K 5,184 [2pts] 80% 5,408 [2pts]+1
Total contractor 60% = $K 6,480 [no point] 6,760 [no point]
vi)
(Average salary at main Office = $K 90; Burden at main Office = 150% = $K 135)
(Average salary at Contractor's = $K 110; Burden at Contractor's = 180% = $K 198)
Cost per employee at Main Office = 2.5*90 = $K 225/year [2pts]
Cost per employee at Contractor's = 2.8*110 = $K 308/year [2pts] OR
Total Cost per employee at Main Office = 225*30/12 = $K [1pts]
Cost per employee at Contractor's = 308*30/12 = $K [1pts]
Total points:

20. PROBLEM 3. If the cost of producing “n” modules decreases polynomially and is given by the equation 50n n while the cost of testing the modules increases exponentially with the number of modules and is given by the equation 3(0.31n) (1.02n)1.01 – 1.14? What is the optimum number of modules in this case?
[NOTE: Use at least 2 decimals in your calculations! while filling in the table below]

21. Make a table and find the minimum cost as follows:
ANSWER TO PROBLEM 3:
Make a table and find the minimum cost as follows:
Eight modules is the optimum number! n
50n n
3(0.31n) (1.02n)1.01 – 1.14
sum 1 93
0.28
93.28 2
80.45
1.73
82.18 3
74.1
3.19
77.29 4
69.98
4.66
74.64 5
66.99
6.14
73.13 6
64.67
7.63
72.3 7
62.79
9.11
71.9 8
61.22
10.6
71.82 9
59.88
12.1
71.98 10
58.71
13.59

22. WE ARE HERE!

23. CHAPTER 6 REQUIREMENTS

24. Regarding a requirement
It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification
Requirements may serve a dual function
May be the basis for a bid for a contract - therefore must be open to interpretation
May be the basis for the contract itself - therefore must be defined in detail
Both these statements may be called requirements
Requirements shall satisfy
Completeness
Consistency

25. Types of requirements Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
Non-functional requirements
constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that domain.

26. Requirement(s) and its specification(s)
Requirement(s) definition - example
The software must (?) provide a means of representing and accessing external files created by other tools.
Requirement(s) specification(s)
1.1 The user should (?) be provided with facilities to define the type of external files
1.2 Each external file may (?) have an associated tool which may (?) be applied to the file.
1.3 Each external file type may (?) be represented as a specific icon on the user’s display.
1.4 Facilities should (?) be provided for the icon representing an external file type to be defined by the user.
1.5 When a user selects an icon representing an external file, the effect on that selection is (?) to apply the tool associated with the type of external file to the file represented by the selected icon.

27. IMPROVING LANGUAGE AMBIGUITY & FIXING LANGUAGE ERRORS
Requirement(s) definition
1. The software shall provide a means of representing external files created by other tools.
2. The software shall provide a means of accessing external files created by other tools.
Requirements specification
1.1 The user shall be provided with facilities to define the type of external files
1.2 Each external file shall have an associated tool which shall be applied to the file.
1.3 Each external file type shall be represented as a specific icon (?) on the user’s display.
1.4 Facilities shall be provided for the icon representing an external file type.
1.5 Facilities shall be defined by the user.
Comment: When a user selects an icon representing an external file, the effect on that
selection is to apply the tool associated with the type of external file to the file
represented by the selected icon.
What is a SIS?, Software Interface Specification

28. Types of requirement User requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers
System requirements
A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor
Software specification
A detailed software description which can serve as a basis for a design or implementation. Written for developers

29. Preparation for Requirements Engineering
1. Prior to actually performing the requirements engineering activities, it is important to plan for the resources, methodology, and time needed to perform this crucial step in software engineering.
2. Some organizations even perform requirements engineering as a separate, stand-alone activity and price it separately, with the option of folding the cost into the whole project if they get the call to complete the software project.

30. Major Requirements Engineering Activities
Elicitation
Documentation and definitions
Prototyping
Analysis
Specification(s)
Review and validations
Gain agreement and acceptance
Note: This list does not address “inventing” new requirements.

31. Requirements Engineering Activities

32. Types of requirement User requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers
System requirements
A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor
Software specification
A detailed software description which can serve as a basis for a design or implementation. Written for developers

33. Why Is This Set of Activities Important and Why Should Requirements Be Documented? (Remember Chaos Report?)
Clear requirements are needed for design and implementation activities.
Requirements documentation is needed to create test cases and test scenarios—especially for large systems where the test team is a separate group of people from the developers.
Requirements document is needed to control potential scope-creep.
Requirements document is needed to create user training material, marketing material, and documents for support and maintenance.
Requirements document provides a way to segment a large project, prioritize releases, and simplify project management.
Think about agile processes where this crucial step may sometimes be
“compromised” by the novice software engineers.

34. Requirements Elicitation
May be given to the software engineers.
Initial product/system requirements
For second and/or third follow-on release of a “planned” sequence of software product where a preliminary set of requirements are already established
Requirements provided as part of a request for price quotation for a software development project
Have to be established by software engineers.
Users sometimes have an understanding of only the requirements related to their specific job tasks.
The business rationale and goals are not always clear to individual user and needs to be established for prioritization reason.
There may be contradicting and incomplete requirements stated by the users and customers.

35. High-Level Requirements Elicitation
Need to seek out the business and management perceptions and goals for the software project.
Business opportunity and business needs
Justification for the project
Scope
Major constraints
Major functionality
Success factor
User characteristics
Software engineers who have to interact with business management
and handle requirements are sometimes called business analysts.

36. Requirements Analysis
Requirements “analysis” is composed of:
Categorizing the requirements (by some criteria)
Prioritizing the requirements
Also “start to look” for consistency and completeness (see VORD Slide)

37. Requirements Classification/Categorization
Most high level:
Functional
Non-functional
Other more detailed grouping also exists.
Six dimensions of requirements

38. Requirements Categorization
By detailed six requirements areas:
Individual functionality
Business flow (usage “scenarios”)
Data and information needs
User interfaces
Other interfaces to external systems/platforms
Various constraints (non-functional)
Performance
Security
Reliability
Etc.

39. Requirements “Analysis/Categorization” of Multiple Views
View-oriented requirements definition (VORD) is based on the concept that requirements are viewed differently by different people.
Identify stakeholders and their viewpoints of the requirements.
Categorize the viewpoints of requirements and eliminate any duplication (look for consistency and completeness).
Refine the identified viewpoints of requirements.
Map the viewpoints of requirements to the system and the services that the system must provide.

40. Requirements Prioritization
Most of the time we have some limitations in developing software:
Time
Resources
Technical capabilities (existing)
We need to prioritize the requirements to satisfy these limitations.

41. Requirements Priorities
Some criteria for prioritization:
Current user/customer demands or needs
Competition and current market condition
Anticipated future and new customer needs
Sales advantages
Existing critical problems in current product
These are often subjective and requirements should be prioritized with the help of many of the stakeholders (different viewpoints).

42. Requirements Comparison and Prioritization
Requirements prioritization is an activity of comparing requirements and placing them in some order relative to each other.
Is it always performed with just experience and gut feel?
and/or
Done with a little more rigor?
Sort by priority groups where the priority groups are based on some prioritization criteria list (e.g., current user needs has the highest priority).
Pair-wise comparison: normalize and compute relative value using some Analytical Hierarchical Process (AHP)

43. Requirements Definition/Prototyping/Review
Once the requirements are solicited, analyzed, and prioritized, more details may/must be spelled out. Three major activities that may be intertwined must be performed:
Requirements definition
Requirements prototyping
Requirements reviewing

44. Requirements Definitions/Documentation
Requirements definitions may be written in different forms:
Simple input/process/output (I-P-O) descriptions in English
Dataflow diagrams (DFD)
Entity relationship diagram (ERD)
Use case diagram from Unified Modeling Language (UML)
Once the requirements are defined in detail using any of the above forms, they still need to be reviewed by the users/customers and other stakeholders.
Formal
review
by others

45. Requirements Definition Using English and Input-Process-Output Diagram Form
English I-P-O: functionality, business, and data flow

46. Flow-Oriented Modeling
Represents how data objects are transformed at they move through the system
A data flow diagram (DFD) is the diagrammatic form that is used to model requirements and its corresponding design.
Note: Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the system that is unique—it should be used to supplement other analysis model elements

47. The Flow Model Every computer-based system is an
information transform ....
computer
based
system
input
output

48. Flow Modeling Notation
external entity
process
data flow
data store

49. External Entity A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based
system
Data must always originate somewhere
and must always be sent to something

50. Process A data transformer (changes input to output)
Examples: compute taxes, determine area,
format report, display graph
Data must always be processed in some
way to achieve system function

51. Data Flow Data flows through a system, beginning
as input and be transformed into output.
base
compute
triangle
area
area
height

52. Data Stores Data is often stored for later use. look-up sensor data
sensor #, type,
location, age
look-up
sensor
data
report required
type,
location, age
sensor number
sensor data

53. Data Flow Diagramming: Guidelines
all icons must be labeled with meaningful names
the DFD evolves through a number of levels of detail
always begin with a context level diagram (also called level 0)
always show external entities at level 0
always label data flow arrows
do not represent procedural logic

54. Constructing a DFD—I
review the data model to isolate data objects and use a grammatical parse to determine “operations”
determine external entities (producers and consumers of data)
create a level 0 DFD

55. Level 0 DFD Example user digital video monitor processor video source
processing
request
user
requested
video
signal
digital
video
processor
monitor
video
source
NTSC
video signal

56. Constructing a DFD—II write a narrative describing the transform
parse to determine next level transforms
“balance” the flow to maintain data flow continuity
develop a level 1 DFD
use a 1:5 (approx.) expansion ratio

57. The Data Flow Hierarchyb x P y
level 0 c a p2 f p1 b p4 d 5 g p3 e
level 1

58. Flow Modeling Notes
each bubble is refined until it does just one thing
the expansion ratio decreases as the number of levels increase
most systems require between 3 and 7 levels for an adequate flow model
a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)

59. Syntax of Data Flow Diagram (DFD)

60. Requirements Definition Using DFD
Captures functionality, business flow, data. 4

61. What is a Relationship? relationship —indicates “connectedness”;
a "fact" that must be "remembered"
by the system and cannot or is not computed
or derived mechanically
several instances of a relationship can exist
objects can be related in many different ways

62. Entity-Relationship Diagram (ERD) Notation
attribute
One common form:
(0, m)
object
relationship
object 1 2
(1, 1)
Another common form:
object
relationship
object 1 2
(0, m)
(1, 1)

63. Building an ERD
Level 1—model all data objects (entities) and their “connections” to one another
Level 2—model all entities and relationships
Level 3—model all entities, relationships, and the attributes that provide further depth

64. The ERD: An Example request Customer for service (1,1) (1,m) (1,1)
places
(1,1)
(1,m)
(1,1)
standard
task table
(1,n)
work
order
generates
(1,1)
(1,1)
(1,1)
(i,1)
selected
from
work
tasks
(1,w)
consists of
(1,w)
(1,i)
materials
lists

65. Requirements Definition Using Entity Relation Diagram (ERD)
Captures relations among data.

66. Requirements Definition Specifying Entity and Attributes
Captures relations among data.

67. Requirements Analysis & Definition Methodology Using UML
Using OO Use Case Methodology and Notation, which identifies:
Basic/main functionalities
Pre-conditions of functionality
Flow of events or scenarios
Post-conditions for the functionality
Error conditions and alternative flows
Using OO Use Case Diagram, which identifies:
Actors (or all external interfaces with the system, including the users)
Related “use cases” (major functionalities)
Boundary conditions
Use cases may be further refined during design.

68. Requirements Definition Using Use Case Diagram (for major functionalities)

69. Requirements Definition Using Use Case Description
Use case diagrams are mostly for functionalities and are not detailed enough—so we need to use “English” text for further descriptions of the requirements:
Functional details
Pre-conditions
Post-conditions
Non-functional characteristics about the functionalities
“Alternative paths” (e.g., error processing)
UI sample (e.g., “looks”)
Etc.

70. Requirements Traceability
Capability to trace a requirement is needed to ensure that the product has fully implemented the requirements (while not part of requirements process activities – it needs to be started early).
We need to trace requirements:
Requirements from source (people and documents)
Requirements to later steps (design, implementation, test, and release)
We also need to link requirements to other “prerequisite” requirements.

71. Partially Filled Traceability Table
Requirement
Design
Code
Test
Other Related
Requirements 1
compon. X
Module 3
Test Case 32
2, 3 2
compon. w
Module 5
Test Case 16 3
Module 2
Test Case 27 4 5 6 7

72. Requirements Prototyping
Requirements prototyping mostly addresses the user interface (UI) part of the requirement in terms of:
Visual looks (size, shape, position, color)
Flow (control and logical flow; depth of flow)
The prototyping may be performed in one of the two modes:
Low fidelity: using paper/cardboard to represent screens and human to move the boards
High fidelity: using automated tools such as Visual Basic to code the screens and direct the logical flow of these screens

73. Requirements Specification
Once the requirements are defined, prototyped, and reviewed, they must be placed into a Requirements Specification document.
IEEE /EIA Standard (may be purchased from IEEE). It outlines the guideline for three major sections of a requirements specification document.
Introduction
High-level description
Detailed descriptions
Details of each functionality (input-output-process)
Interfaces, including user interfaces and network interfaces
Performance requirements (response time, throughput, etc.)
Design constraints, standards, etc.
Additional attributes such as security, reliability, etc.
Any additional unique requirements

74. Finally — Requirements “Sign-Off”
Having a requirements specification agreed to and signed off on is important.
Serves as a milestone marker and formally exits a phase of software engineering.
Serves as baseline from which any future changes can be monitored and controlled.
Remember “agile”—which wants less “legalese” like sign-off
—obviously, I disagree when it comes to large/expensive projects!