1. Requirements Engineering
Developing and Managing Requirements
Requirements Engineering
A set of activities or tasks that help engineers better understand the problem to be solved.
Answers questions such as:
What does the customer want?
How would the end-user interact with the product?
What is the business impact of the product?

2. Requirements Engineering Tasks
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Management
Not sequential, but Inception usually occurs early in the process.
Very Important Points
The SME/customer/user/worker must be a primary source of information throughout the Requirements Engineering (Analysis) process.
The SME is a major driver of requirements.
Requirements drive the design and are the basis for evaluation.

3. Inception: Getting Started
Context free questions to understand:
basic problem at hand
people who want the solution
nature of the solution that is desired
Some questions that need answers:
Who is behind the request for this work?
Who will use the solution?
How would you characterize “good” output of a solution?
What problems will this solution address?
Should I be asking you anything else?
Am I asking too many questions?
Other questions that may need answers:
What will be the economical benefit of a successful solution?
Is there another source for the solution that you need?
Can you show me or describe the business environment in which the solution would be used?
Will special performance issues or constraints affect the way the solution is approached?
Are you the right person to answer this question? Are your answers official?
Are my questions relevant to the problem that you have?
Can anyone else provide additional information?

4. Elicitation: Getting Requirements Out Of the Customer and Other Sources
Goals:
To establish
scope of the problem.
overall perception of the solution of the problem, i.e.,
the product
the re-engineered system
To understand
the system.
parts of the environment that surround the system.
other objects that are to be produced by the system.
objects that are used by the system to perform its functions.
processes or functions that manipulate or interact with the objects.
constraints (i.e. cost, size, business rules).
performance criteria (i.e. speed accuracy).
requirements volatility.

5. Elaboration: Refining, Adding Detail
Goals:
To refine information gathered from inception and elicitation.
To develop system models.
To identify features of the system.
To identify constraints for the system.
Tools
User scenarios (use cases)
System models (from System Analysis)
Personnel Descriptions
Environment Descriptions
Equipment &Facilities Models
Drawings, Layouts
Functional or process models, e.g.,
(Flow) process charts
Flow Diagrams
IDEF0 models

6. Negotiation: Compromising the Ideal and the Real
Considerations
Technical Limitations
Economic Limitations
Design Team Limitations
Tool Limitations
Time Constraints
Space, Capacity Limitations
etc.
Usually customers and users ask more than what is achievable given the time and budget.
Issues are resolved through the process of negotiation.
Requirements are ranked and risk associated with each is analyzed.
The most important and critical requirements are prioritized and agreement between the parties is reached.

7. Specification: Representing the Requirements
Guidelines for a Requirements Document:
Requirements state something:
Necessary
Verifiable
Attainable
and they state it clearly.
Common Problems:
Making bad assumptions
Writing implementation (HOW) instead of requirements (WHAT)
Describing operations instead of writing requirements
Using incorrect terms
Using incorrect sentence structure or bad grammar
Missing requirements
Over-specifying
The representation of the requirements.
Can take multiple forms:
Written Requirements Document
Graphical Models
Formal Mathematical Models
Collections of user scenarios
Prototypes
Combinations of the above

8. Making bad assumptions
No access to appropriate information
Solution: Make information available to all authors by, e.g.,
Notebook
Website
Information does not exist
Solution: Authors should document all assumptions

9. Writing implementation (HOW) instead of requirements (WHAT)
Example:
The workstation shall include an RDM hydraulic lift, adjustable-height work table. (IMPLEMENTATION)
The requirement should state WHAT is needed not HOW it is to be provided.
Solution: Ask the question: WHY do you need the requirement?
See

10. Writing implementation (HOW) instead of requirements (WHAT)
Answers:
Workers of various sizes will use the workstation.
A typical workpiece requires handwork about four inches above the surface supporting it.
By ergonomic guidelines, the workpiece should be slightly below elbow level.
This is real requirement:
The workstation shall be adjustable so that the work surface is 4 in below the elbow level of the worker.
It leaves lots of options open for implementation.

11. Describing operations instead of writing requirements
Similar to the implementation problem
Examples:
Tools shall be returned to dedicated storage spaces when they are no longer needed. (OPERATION)
Workers shall place the parts needed for each widget in a separate container for temporary storage and transportation. (OPERATION)
Real Requirements:
A dedicated storage space shall be provided for each tool.
A means shall be provided for temporary storage and transportations of the parts required for each widget.

12. Using Incorrect Terms Use of Terms: Requirements use the word “shall”.
Statements of fact use “will”.
Goals use “should”.
Terms to avoid:
support
but not limited to
etc.
and/or

13. Using incorrect sentence structure or bad grammar
Requirements should be easy to read and understand.
Format:
The work system shall provide…
The work system shall be capable of …
The work system shall weigh …
Subsystem #1 shall provide
Subsystem #2 shall interface with …
Note: the name of the system and subsystem appears in these locations, if the system name is complex, use acronyms.
Guidelines:
Each “shall” should be followed by a single predicate, not by a list.
Should not be complicated by explanation of operations, design or other information.

14. Unverifiable Requirements
Avoid ambiguous terms:
Minimize
Maximize
Rapid
User-friendly
Easy
Sufficient
Adequate
Quick
Be specific.
How rapid? 10 per hour, 5 per hour.
What is sufficient? 10 units, 100 units.
What is user-friendly?
If you are not sure yet,
enclose the term in asterisks (e.g., *rapid*).

15. Missing requirements
Use the elaboration tools to make sure every aspect of the system is specified.
Requirements Drivers (i.e., things to think about):
Functional – Reliability
Performance – Maintainability
Interface – Operability
Environment – Safety
Facility – Regulatory
Transportation – Security
Deployment – Privacy
Training – Design constraints
Personnel – Usability

16. Over-specifying Major cause of cost overruns and delivery time delays.
Ask the question why it is needed before writing it as a requirement.
Be aware of over stringent requirements
Allow for tolerances (i.e. if height of a table is specified to be 1000 mm allow for variations, such as /- 10mm)

17. Validation: Making Sure the Requirements Are Correct
Examine the requirements for:
Ambiguity
Inconsistencies
Omissions
Errors
Validation reviewers:
Engineers
Users
Customers
Other stakeholders

18. Requirements Management
IE 366 Requirements Management
Organize requirements by system processes
Recorded in WSE workbook (OO Calc/MS Excel)
Information to be recorded, updated
Requirement Number
Requirement Text
Process/Activity ID & Name
Author
Requirement Status
preliminary: not yet verifiable
≈ House of Quality Customer Requirement
unmet: verifiable but not yet met
≈ HoQ Engineering Requirement (unmet)
met: verifiable and met
≈ HoQ ER (met)
Test Procedure
Comment
Requirements evolve throughout the project, so they need to be managed.
(Optional) Traceability tables used to make sure every requirement has been met upon completion of the project.
Traceability tables:
relate requirements with parts of the system or environment
relate requirements with customer needs
relate requirements to one another
categorize requirements by the subsystem that they govern
relate requirements to user needs and interfaces

19. Requirements Examples