1. ITEC 6120 System Requirements Management
Luiz Marcio Cysneiros
Fall 2017

2. Textbook Requirements engineering : processes and techniques
Textbook
Requirements engineering : processes and techniques
Gerald Kotonya and Ian Sommerville.
Publication info: Chichester ; New York : J. Wiley & Sons, c1998. ISBN:

3. Scoring Oral Presentation + Leading discussion 45% Final exam 55%
Scoring
Oral Presentation +
Leading discussion %
Final exam 55%

4. Directions email cysneiro@yorku.ca office TEL Building 3053
Directions
office TEL Building 3053
Office Hours – Tuesday: 2:30 PM to 3:30 PM Wednesday 5:00 PM to 6:30 PM

9. Course Objectives Understanding RE Research in RE
RE State-of-the-art for research and Practice
What does a RE do ?
Techniques
Methods
Process
Understanding RE
Research in RE
Existing Methods
Where it will lead us ?
Alternatives ?

10. The Course at a Glance Introduction Elicitation Modelling Analysis
Management
Advanced Topics: Goal/Agent-Oriented RE, Social Modelling for RE

11. Nowadays World Software-Intensive Systems Software vs Systems ?
Software Alone is useless
Hardware Alone is useless
Both only exist when used to support any human activity
Software+Hardware+People+activities
Systems
Intensive use of software systems

12. Systems/Requirements Analyst
Person who performs systems analysis
Different possible job titles
Systems analyst
Business systems analyst
Business analyst
Process analyst
Requirements engineer
Requirements analyst
Product owner
Role is evolving
Systems analyst [WB*]
a specialist who studies the problems and needs of an organization to determine how people, data, processes, and information technology can best accomplish improvements for the business
* [WB - Whitten, J. L., Bentley, L. D. Systems Analysis and
Design Methods,7th edition, Irwin McGraw-Hill, 2007]

13. Skills for a Systems Analyst
Problem solving
Business acumen
Domain expertise
IT knowledge (IS, various technologies, programming)
Communication
Dealing with business and technical (IT) people
Interviewing, meeting facilitation, etc.
Liaison b/w business and IT

14. What is a System?
A system is a group of interrelated components that function together to achieve a desired result [WB]
System [Alter]
Social – no significant use of technology
Sociotechnical – human participants make use of technology
Automated – fully automated once triggered by people, events, etc.
An information system (IS) is an arrangement of people, data, processes, and information technology that interact to collect, process, store, and provide as output the information needed to support an organization [WB]

15. More System Definitions
Macmillan English Dictionary
A set of connected things that work together for a particular purpose
A central heating system
I decided to install a security system to prevent any break-ins.
The city’s inadequate public transportation system

16. More System Definitions
Ackoff [Russell L. Ackoff. Towards a System of Systems Concepts. Management science, 17(11), ]
Set of (at least two) interrelated elements/components
Each element is connected to every other element (directly or indirectly)
No subset of elements is unrelated to any other subset
Weinberg [Gerald M. Weinberg. Introduction to General Systems Thinking, 1975]
“A system is a way of looking at the world”
Systems don’t really exist!
Just a convenient way to describe things (e.g., just like “sets”)

17. Nowadays World Software systems present opportunities for change
It may be complex but should also be adaptable
Changes very quickly and some times very frequently
A New System may change human activities in many significant ways
Paperless Hospitals
Virtual Doctors
Virtual Surgeries
Phone Chat
Facebook

18. Nowadays World Software Systems became Ubiquitous
Even Refrigerators have software systems today
However, we are frequently disappointed with them
If it doesn’t work chances are :
Who designed didn’t understood what was needed
It is been used for different purposes than the original intended

20. Requirement: (Macmillan English Dictionary)
something that is needed in order for something to happen:
Check the car’s fuel requirements.
Good insulation can cut the energy requirements of a house by more than half.
something that a rule, law, contract, etc. states that you must do:
Do these goods comply with our safety requirements?
requirement of: It is usually a requirement of banks and investors that a new company is formed to effect the management buy-out.
requirement for: Applicants must satisfy the requirements for admission to the university.

21. System: (Macmillan English Dictionary)
[count] a set of connected things that work together for a particular purpose:
a central heating system
I decided to install a security system to prevent any break-ins.
the city’s inadequate public transportation system
System: some part of a reality that can be observed to interact with its environment a set of interrelated components, or sub-systems, with a particular purpose. 1) there are 2 components at least, 2) each of which is related (directly or indirectly) to every other component and, 3) no sub set of which is unrelated to any other subset. Ackoff, Russell L., (1971). Towards a System of Systems Concepts. Management science, 17(11), SOFTWARE VS SYSTEMS ?

22. Context Software crises continues Denver Airport
More than 50 million US $ due to errors in the baggage control system
London Ambulance Service
The system was deactivated one day after its deployment due to many errors. Most of them related to non-functional requirements such as: Safety, Reliability and Usability

23. Software Crises Flaws in the Production Process Unhappy Clients
High costs

24. Europe Questionnaire sent to 3.805 companies showed:
For the Analysts, Major problems are:
Requirements specification (53%)
Requirements Management (43%)
Documentation (36%)
Test (35%)

25. USA
Requirements Management (Also know as Requirements Engineering – RE) is seen as one of the most important problems to be overcome in order for companies to achieve level 2 in the SEI’s (Software Engineering Institute – Carnegie Mellon) CMM (Capability Maturity Model)
SEI has recently released a package aiming to transfer technology in RE to facilitate companies’ certification

26. Good News … “26% of the Software projects were considered a success.”
Standish Group, CHAOS Report, 2000

27. Bad News… Meaning that 74% have FAILED!
Standish Group, CHAOS Report, 2000

28. Even Worse: CHAOS Report, 2015. The Standish Group.
“29% of the Software projects were considered a success.”
Almost two-fold increase from 1994!
But this means that 71% were not (fully) successful!

29. CHAOS Reports Widely cited (since 1994)
Type 1. Project success: completed on-time and on-budget, with all features and functions as initially specified
Type 2. Project challenged: completed and operational but over- budget, over the time estimate, and offers fewer features and functions than originally specified
Type 3. Project impaired: project is canceled at some point during the development cycle

30. From the CHAOS Reports

31. From the CHAOS Reports

32. From the CHAOS Reports

33. Tom De Marco
“56% of the errors in a software can be traced back to the requirements phase”
The later an error is detected the more expensive is to fix it.
Many errors are done during Requirements elicitation and analysis

34. Many errors in requirements can (and should) be detected early in the software development life cycle.
Typical errors include: Use of incorrect facts, omission, inconsistency and ambiguity.
Errors in requirements specification are one of the major concerns for software industry.

35. 200 x Cost to Repair Analysis Design Code Unit Test Integration Test
Maintenance
Stage when the Error is found

36. Definition of RE
“ Requirements engineering is a sub-area of Software Engineering that studies the process of defining the requirements for a software-to-be. It is a new area started in 1993 when the 1st International Symposium on RE was organized.
The process for defining requirements is an interface between the desires and the needs of the clients and a future implementation of these requirements as a software.”

38. Goals Understand the needs and support the client’s desires.
Provide the Requirements Engineer with methods, techniques and tools to help on the process of understanding and registering what a software must do.

39. Fred Brook’s Brook adds:
“The most difficult part of building a software system is to decide, precisely, what must be built. No other part of the work can undermine so badly the resulting software if not done correctly. No other part is so difficult to fix later.”

40. Factors influencing requirements
Personality and status of stakeholders
The personal goals of individuals within an organization
The degree of political influence of stakeholders within an organization

41. RE process problems Lack of stakeholder involvement
Business needs not considered
Lack of requirements management
Lack of defined responsibilities
Stakeholder communication problems
Over-long schedules and poor quality requirements documents
Many confuse it with Design
Pressure from the Market
“It has to be ready next week”
Clients keep adding and changing things

42. Process improvement
Process improvement is concerned with modifying processes in order to meet some improvement objectives
Improvement objectives
Quality improvement
Schedule reduction
Resource reduction

43. Planning process improvement
What are the problems with current processes?
What are the improvement goals?
How can process improvement be introduced to achieve these goals?
How should process improvements be controlled and managed?

44. Process maturity
Process maturity can be thought of as the extent that an organization has defined its processes, actively controls these processes and provides systematic human and computer-based support for them.
The SEI’s Capability Maturity Model is a framework for assessing software process maturity in development organizations

45. Capability maturity model

46. RE process maturity levels
Initial level
No defined RE process. Suffer from requirements problems such as requirements volatility, unsatisfied stakeholders and high rework costs. Dependent on individual skills and experience.
Repeatable level
Defined standards for requirements documents and policies and procedures for requirements management.
Defined level
Defined RE process based on good practices and techniques. Active process improvement process in place.

47. Maturity levels Managed level Optimizing level
Detailed measurements of both process and product quality are collected and used to control the process.
Optimizing level
The organization has a continuous process improvement strategy, based on objective measurements in place.

48. Good practice for RE process improvement
RE processes can be improved by the systematic introduction of good requirements engineering practice
Each improvement cycle identifies good practice guidelines and works to introduce them in an organization

49. Project Management + Mature Process
Metrics ! A critical tool
If you don’t have metrics you can not manage it
Milestones
People
Productivity
Mistakes
Time to fix mistakes
Etc.

50. 2015

51. Why Requirements Engineering?
Von Neumann:
“There is no sense in being precise when you don’t even know what you are talking about”

52. Context The Blank Page Fallacy The Completeness Fallacy
Social Aspects Involved

53. So, What are Requirements?
Clients
Users
Needs
Limitations
Impossibilities
Technological Infra-Structure

54. Definition Software Requirements
Sentences that express clients’ needs and establish the desired quality

55. Types of Requirements Functional Requirements
FR are the requirements that are directly related to the software functionality.
What the system must do !
Non-Functional Requirements
NFRs express constraints that a software must comply with.
Can be seen as specific qualities that a software must have
“How” the software must do the “What”
Ex: Safety, accuracy, usability, security
Requirements-1 (Inverse Requirements)
IR establish conditions that must never happen
Frequently associated to an NFR

56. After all, What are Requirement?
Clients FR
Users
Needs
Limitations
Impossibilities
NFR
NFR IR
Technological Infra-Structure

57. Examples
The system should provide a form to enter results for clinical tests performed for a client (FR)
Depending on the result of the test, only the Supervisor can entry the result for this patient. E.g. Glucose over 8.0 (NFR Safety)
The system should give the client a receipt. This should take no longer than 8 sec (FR “.” NFR Performance)
The system can not erase any client information (IN)

58. Definitions Universe of Discourse
Is the context in which the software should be developed and operated. UofD includes all sources of information and all people related to the software. These people are also known as the actors of this universe. UofD is a reality circumstantiated by the set of goals defined by those who demand the software

59. Information Systems
Universe of Discourse
Macrosystem
Software
System

60. organization
hardware
Information System
software

62. An SADT Model for the Definition of Requirements
UofD
Select
Personel
Soft. Eng. Viewpoints
clients
method
UofD
Elicit
facts
Model
requirements
model
UofD
Analyse
Select
Method
tools

63. The “Requirements Lifecycle”
Not Waterfall
Not Spiral
Not Iterative

65. Books
Requirements Engineering: Processes and Techniques by Ian Sommerville, Gerald Kotonya (September 1998) John Wiley & Son Ltd; ISBN: Amazon.com Sales Rank: 188,502
System Requirements Engineering by Pericles Loucopoulos, Vassilios Karakostas (June 1995) McGraw Hill Text; ISBN: Amazon.com Sales Rank: 1,067,908
Software Requirements & Specifications : A Lexicon of Practice, Principles and Prejudices by Michael Jackson (July 1995) Addison-Wesley Pub Co; ISBN: Amazon.com Sales Rank: 38,607

66. More Books
Exploring Requirements : Quality Before Design by Donald C. Gause and Gerald M. Weinberg (September 1989) Dorset House; ISBN: Amazon.com Sales Rank: 13,641
Mastering the Requirements Process by Suzanne Robertson, James Robertson (May 4, 2000) Addison-Wesley Pub Co; ISBN: ; Dimensions (in inches): 0.93 x 9.50 x 7.66 Amazon.com Sales Rank: 7,392
Managing Software Requirements: A Unified Approach (The Addison- Wesley Object Technology Series)by Dean Leffingwell, Don Widrig (November 1999),Addison-Wesley Pub Co; ISBN: Dimensions (in Inches): 1.13 x 9.46 x 7.76 Amazon.com Sales Rank: 14,447

67. Reading for next Class
Requirements Engineering - a roadmap - Nuseibeh, Easterbrook – First Presentation
[Goguen94] - Goguen, J.A. and Linde, C. - Techiques for Requirements Elicitation, In   Proceedings of the First IEEE International Symposium on Requirements Engineering, San Diego, Ca, IEEE Computer Society Press ,  pp  
[Goguen94a] - Goguen, Joseph - Requirements Engineering as the reconciliation of social and technical issues - in Requirements Engineering: Social and Technical Issues edited by Joseph Goguen and Marina Jirotka - Academic Press 1994.
Download from course page