1. Requirements Engineering
Week 1 & 2
Introduction
Dr. Eman Al-Maghary

2. Agenda
Software Lifecycle and Software Processes
Introduction to RE

3. Engineering Character of Software Development
Large software development project requires an Engineering approach:
Life-Cycle
Teamwork
Requires an overall plan, organization and communication

4. Some Process Models Waterfall RUP: Specialized: Formal Methods
Incremental
Iterative
Specialized: Formal Methods

5. The Linear (Waterfall) Model
Modeled after a conventional engineering cycle
Assumes that a complete system will be delivered after the linear sequence is completed
Problems: customer has to sate all requirements explicitly; doesn’t support change; customer can see a working version of the program until code phase.
old fashioned but reasonable approach when requirements are well understood

6. Waterfall Model: Discussion
Assumes that a complete system will be delivered after the linear sequence is completed
Problems:
customer has to state all requirements explicitly;
doesn’t support change;
customer can’t see a working version of the program until code phase.

7. Rational Unified Process (RUP)

8. “Mini-Waterfall” Process
RUP Iteration Process
Inception
Elaboration
Construction
Transition
Iteration 1
Iteration 2
Iteration 3
“Mini-Waterfall” Process
Iteration Planning
Rqmts Capture
Analysis & Design
Implementation
Test
Prepare Release

9. Unified Process: Iterative Life Cycle
Main reason for using the iterative life cycle:
You do not have all the information you need up front
Things will change during the development period

10. Phases in the RUP
Inception: group the project’s risks by building a proof of concept. Establish a business case of the system. Identify external entities (people and systems) that will interact with the system and define these interactions. Access contribution to the system.
Elaboration:
Develop a common understanding of the system’s scope and desired behavior
Address system-wide issues (activities and resources)
Elaboration:
Architectural framework of the system, Project plan, identify key project risks
On the completion of this phase u should have: a requirements model(use case), an architectural description and a development plan for the software

11. Phases in the RUP(Cont.)
Construction: build the product
Risk-Driven iterations
Continuous integration
(concerned with system design, programming and testing)
Transition: deliver the product to the user’s community
Facilitate user acceptance
Measure user satisfaction

12. Selecting Iterations
The first iteration:
Be modest regarding the amount of functionality that can be achieved in the first iteration
Teams new to an iterative approach are usually overoptimistic
How many iterations do I need?
On projects taking 18 months or less, 3 to 6 iterations are typical

13. Iteration Assessment
Assess iteration results (functionality, performance, quality)
Consider external changes that have occurred during this iteration (changes to requirements, changes to user needs, competitor plans)
Determine what rework is required and assign it to the remaining iterations

14. RUP: Key points
Defines the function of the system from the user point of view applying scenario-based approach.
Uses Unified Modeling Language (UML): industrial standard notation
Rational: a software tools supporting UP and UML, used widely in industry
Unified Software Development Process (UP) is representative of CBD models that are used in industry.

15. Modeling: Bridge between Requirements and Solution
Modeling a system involves:
identifying the things that are important to your particular view
Their properties
consider how specific instances of these things must fit together.
Modeling a system is affected by how you expect to use the system
Example: NEXT
These things are from the vocabulary of the system you are modeling. For example, if you are building a house , things like walls, doors, windows, cabinets, and lights are some of the things that will be important to a home owner. Each of these things can be distinguished from the other. Each of them has a set of properties. Walls have a height and a width and are solid. Doors also have a height and width and are solid, as well, but have the additional behavior that allows them to open in one direction. Windows are similar to doors have slightly different properties. Windows are usually (but not always) designed so that you can get out of them instead of pass through them.
Individual walls, doors, and windows rarely exist in isolation, so you must also consider how specific instances of these things must fit together. The things you identify and the relationships you choose to establish among them will be affected by how you expect to use the various room to room, and the general style and feel you want this arrangement to create. .
Users will be concerned about different things. For example, the plumbers who help build your house will be interested in things like drains, traps, and vents. You, as a home owner, won’t necessarily care about these things except in so far as they interact with the things in your view, where a drain might be placed in a floor or where a vent might intersect with the roof line.

16. Requirements Gathering: Dice Game
Requirements gathering is the Starting Point (WHAT, i.e., problem oriented)
Dice Game:
A player plays the dice game
the dice game includes two dice.
A player rolls two dice.
If the total is seven, the player wins; otherwise the player loses.

17. How Do You Expect to Use the Dice Game ?
“Happy end” scenario
User:
I want to play this game.
Dice Game:
Roll two dice.
System:
CONGRATULATIONS! You won the game.

18. How Do You Expect to Use the Dice Game ?
Not so “happy end” scenario
User:
I want to play this game.
Dice Game:
Roll two dice.
System:
Looser, try again …

19. Modeling: Dice Game Dice Game: A player plays the dice game
Modeling Features:
Dice Game:
A player plays the dice game
the dice game includes two dice.
A player rolls two dice.
If the total is seven, the player wins; otherwise the player loses.
Play with two dice

20. Modeling: Dice Game Modeling Structure Rolls Plays Includes Player
name 1 2
Die
FaceValue
highly-creative activity. It’s hard to measure a good design objectively 1 2
Plays
DiceGame
total 1 1
Includes

21. Modeling: Dice Game Modeling Behavior : DiceGame Die1: Die Die2:Die
Play()
GetFaceValue()
roll()
Total()
Result()
highly-creative activity. It’s hard to measure a good design objectively

22. Modeling Requirements: Requirements Specifications
Definition: “Specifications represent a model of how inputs are related to system reactions and outputs”
Specification is an ABSTRACTION of the Requirements
Specifications will increase the technical level of details given in the requirements

23. Modeling of The Problem: Problems?
Abstraction might capture only part of the real world truth (i.e., incomplete)
A book may have more than one writers
Somebody else is paid to write the book …
Domain Knowledge is required
Complexity of the Problem is an issue

24. Software Complexity Large and Complex software systems:
Complex: Overall Behavior can only be predicted with some degree of uncertainty
Large: systems built with a large number of components
Size complexity: the vast amount of information to be gathered and analyzed during the requirements & specification stage may cause incorrect and incomplete specification
Other sources for complexity:
Environmental complexity
Problem domain complexity
Communication complexity
Simple software systems:
Characterized by total predictability and small size

25. Specialized Process Models: The Formal Methods Model
Formal method— process to apply when a mathematical specification is to be developed
Enable software engineers to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation.
Offers (the promise of) defect-free software
Training is required
Cleanroom software engineering—emphasizes error detection before testing. Currently applied in industry.

26. Software Engineering: Key Points
SE: A discipline for the systematic production and maintenance of software developed by a team, which is
fault-free,
delivered on time,
within budget, and
satisfies the user’s needs
GOAL: to produce a good quality software that is useful for people

27. Agenda
Software Lifecycle and Software Processes
Introduction to RE

28. What is a Good Quality Software?
A software is good if it MEETS CUSTOMERS EXPECTATIONS:
it is (at least) correct, reliable, maintainable, user-friendly …
the total cost it incurs over all phases of its life cycle is minimal and within the budget

29. Why Comprehension of User Requirements is Important?
RE objectives:
Unambiguous, complete and consistent problem documentation.
Barriers to requirements elicitation
“Yes, But” syndrome
“The Undiscovered Ruins” syndrome
“The User and The Developer” syndrome
Techniques: interviews, workshops, storyboards
Rely on individual’s ability in communicating with the stakeholders

30. Stakeholders in SE Customers Users Software developers
Those who pay for the software
Users
Those who use the software
Software developers
Development Managers

31. Stakeholder Needs (extracted from the slides of Peter Hauker, Rational)

32. Features of the System (extracted from the slides of Peter Hauker, Rational)

33. Software Requirements (extracted from the slides of Peter Hauker, Rational)

34. How Do We … ? … know what the system is supposed to do?
By proper requirements development
… keep track of the current status of requirements?
… determine the impact of a requirements change?
By proper requirements management

35. Requirements Engineering: General View

36. Requirements Development Process
Elicitation: work with the customer on gathering requirements
Analysis: process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements
Specification: Structure the customer input and derived requirements as written documents and diagrams
Validation: you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors.
This iterative process continues throughout requirements development
No single formulaic approach to requirements development.
Structure the customer input and derived requirements as written documents and diagrams
process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements
work with the customer on gathering requirements
you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors

37. Requirements Development Process
Elicitation: work with the customer on gathering requirements
Analysis: process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements
Specification: Structure the customer input and derived requirements as written documents and diagrams
Validation: you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors.
This iterative process continues throughout requirements development, No single formulaic approach to requirements development.

38. Software-Intensive Systems
Software (on its own) is useless
Software is an abstract description of a set of computations
Software only becomes useful when run on some hardware
we sometimes take the hardware for granted
Software + Hardware = “Computer System”
A Computer System (on its own) is useless
Only useful in the context of some human activity that it can support
we sometimes take the human context for granted

39. Software-Intensive Systems (cont.)
A new computer system will change human activities in significant ways
Software + Hardware + Human Activities = “Software-Intensive System”
‘Software’ makes many things possible
It is complex and adaptable
It can be rapidly changed on-the-fly
It turns general-purpose hardware into a huge variety of useful machines

40. Quality = Fitness for purpose
Software technology is everywhere
Affects nearly all aspects of our lives
But our experience of software technology is often frustrating/disappointing
Software is designed for a purpose
If it doesn’t work well then either:
…the designer didn’t have an adequate understanding of the purpose
…or we are using the software for a purpose different from the intended one
Requirements analysis is about identifying this purpose
Inadequate understanding of the purpose leads to poor quality software

41. Quality = Fitness for purpose (cont.)
The purpose is found in human activities
E.g. Purpose of a banking system comes from the business activities of banks and the needs of their customers
The purpose is often complex:
Many different kinds of people and activities
Conflicting interests among them

42. Complexity of Purpose People and software are closely-coupled
Complex modes of interaction
Long duration of interaction
Mixed-initiative interaction
Socially-situated interaction
…software systems and human activity shape each other in complex ways
The problems we’d like software to solve are “wicked”
No definitive formulation of the problem
No stopping rule (each solution leads to new insights)
Solutions are not right or wrong
No objective test of how good a solution is (subjective judgment needed)
Each problem is unique (no other problem is exactly like it)
Each problem can be treated as a symptom of another problem
Problems often have strong political, ethical or professional dimensions

43. Dealing with problem complexity
Abstraction
Ignore detail to see the big picture
Treat objects as the same by ignoring certain differences
(beware: every abstraction involves choice over what is important)
Decomposition
Partition a problem into independent pieces, to study separately
(beware: the parts are rarely independent really)

44. Dealing with problem complexity (cont.)
Projection
Separate different concerns (views) and describe them separately
Different from decomposition as it does not partition the problem space
(beware: different views will be inconsistent most of the time)
Modularization
Choose structures that are stable over time, to localize change
(beware: any structure will make some changes easier and others harder)

45. Definition of RE
Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software intensive technologies.

46. Cost of getting it wrong
Cost of fixing errors
Typical development process:
requirements analysis ⇒ software design ⇒ programming ⇒ development testing ⇒ acceptance testing ⇒ operation
Errors cost more to fix the longer they are undetected
E.g. A requirements error found in testing costs 100 times more than a programming error found in testing
Causes of project failure
Survey of US software projects by the Standish group:
Top 3 success factors: 1) User involvement 2) Executive management support 3) Clear statement of requirements
Top 3 factors leading to failure: 1) Lack of user input 2) Incomplete requirements & specs 3) Changing requirements & specs

47. Requirements Problems
Requirements don’t reflect real needs of the customer
Requirements are inconsistent and/or incomplete
It is expensive to make changes to requirements after they have been agreed
There are misunderstandings between customers and developers

48. Requirements Phase The requirements phase:
Elicitation of systems requirements as specified by the user
Review of these requirements for ambiguities and inconsistencies
Transformation of the requirements to a description of what the software will do without describing how it will do it.

49. System Requirements Elicitation
Elicitation of accurate requirements is important because
The later in the development life cycle that a software error is detected, the more expensive it will be to repair
Many errors remain latent and are not detected until well after the phase during which they are made
Many requirement errors are made

50. Requirements Document
Formal document used to communicate requirements to customers, engineers and managers
Serves as the baseline for the system
Must be formally changed via a change control process
IEEE Std. 830: 1998 (I will it to you)

51. Requirements Document
Describes the following
services and functions of the system
system constraints
emergent properties
identification of system integration to other systems
domain information
development process constraints