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?

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.

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?

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.

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

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.

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

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

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 http://www.rdm-ind.com/x-gallery-workbench.htm?gclid=CJCYsczOgZ8CFRT6agodI2E_mg

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.

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.

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

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.

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*).

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

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 1000 +/- 10mm)

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

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

Requirements Examples