Software Requirements Engineering Fundamentals

Has a SW shortage ever frustrated you?

• The size of the worldwide software industry in is measured in billions in an annual bases
• Errors introduced during requirements activities account for 40 to 50 pecrcent of all defects found in SW products
• The hardest single part of conceptually defining a software system is the task of defining the software requirements.
• “no other part of the work so cripples the resulting system if done wrong” and “no other part is more difficult to rectify later” (Brooks, 1987)

• CLO1: Recognize the different types of requirements and importance of software requirement engineering.
• CLO2: Identify multiple techniques to elicit requirements from stakeholders, choosing from among alternative methods as appropriate for different situations.
• CLO3: Analyze documenting requirements for high-level software requirements engineering.
• CLO4: Design and develop models for requirement documentation using goals, use cases, UML class and activity diagrams and state charts.
• CLO5: Evaluate the software requirements using validation and negotiation techniques regarding priorities and scope with the stakeholders.
• CLO6: Measure the documented requirements using quality criteria techniques for accuracy, unambiguity, consistent and completeness of the requirements.
• CLO7: Demonstrate the management of requirements as they change over time. (e.g., over multiple releases and over a product line)

• Identify a real problem in any domain of your choice where you think a SW solution is needed to solve the problem
• Identify real problem stakeholders
• Conduct what you’ve learned about RE in order to capture stakeholders needs and produce a Software Requirements Specification (SRS) for your proposed solution

Software Requirements Fundamentals

• A statement which translates or expresses a need and its associated constraints and conditions (IEEE/ISO/IEC 29148-2018)
• At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world (SWEBOK V3)

Types of Requirements

• Derived from application domain
• Describe system characteristics and features that reflect the domain
• May be new functional requirements or constraints on existing requirements
• Example: “A patient’s designated physician is the only entity allowed to retrieve a patient’s medical reports”.

Why RE?

• GIRES (Gestion intégrée des ressources)
  • To replace >1000 existing systems in 140 organisations / departments
  • Affecting 68,000 employees
• The project started in 1998 with an estimated timeframe of 8 years and a budget of $80 million
• Could not cope with changes to the requirements and was cancelled in 2003 after investing
• Total cost: $400 million

Inception: Start the process (business need, market opportunity, great idea), business case, feasibility study, system scope, risks, etc.

Elicitation: All the tasks involved with discovering and gathering the requirements (interviews, document analysis) Analysis: Develop a deep understating of the requirements on an individual level and as a whole (decomposition, conflicts, gaps) Specification: Documenting these requirements in a well-organized way suitable for comprehension by their intended audiences.

Validation: Reviewing the documented requirements by internal teams and the customer to confirm that it’s complete and properly represented and that it meets the customer needs.

Management: Managing the requirements beyond being agreed upon and through implementation up until the project is completed (tracing reqs, tracking status, changes – scope, assessing impact, accepting or refusing) Regardless of what development life cycle is being used (waterfall, iterative, agile, ...etc.) these are the thing you need to

do

regarding requirements.

Iteration is key to requirements development success.

• A process is a sequence of steps performed for a given purpose (e.g. SW development process)
• RE is a process, not a discrete activity

• Lack of the right expertise
• Insufficient user involvement
• Overlooked stakeholders
• Unrealistic or unclear goals
• Ambiguous requirements
• Conflicting requirements
• Creeping user requirements
• Changing requirements