REQE Introduction

What is a requirement

• "A condition or capability that must be met or possessed by a system or system component satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component"
• Requirements can be : things a system must do, qualities a system must have, constraints that a system must satisfy.

What is requirements engineering

• Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families.
• Preciseness is the key to validation and verification.
• Requirements is the "What" and the design is the "How"
• Requirements must separate out the requirements from the design decisions.
• RE goes beyond general Systems Analysis and focuses on the software.
• Makes sure that needs and goals of a business are satisfied by precise product specification.
• A lot of RE is concerned with system requirements and deriving software requirements from it.
• Layering Abstraction
  • For large systems, difficult to specify the what from the how.
  • The how of one layer forms the what of the next layer.
  • For e.g. the user needs a student record system. The system needs a relational database. The relational database needs a Storage Area Network and so on.
  • As we go deeper in the layers of abstraction, it becomes harder to trace back to the original requirements.

Why is RE Important

• Software is complex and highly modifiable.
• Software is costly to develop and repairing defects is expensive.
• Hence early modeling and analysis is important.
• Not just that, there is a need to communicate req's, seek consensus, keep req's up to date etc.
• RE involves non technical disciplines such as psychology, sociology, anthropology and linguistics.

Participants in RE

• Stakeholders - People/Organizations who will be affected by the system and who directly or indirectly influence the system requirements.
  • Direct Stakeholders - Operators and Users, Customers and Clients.
  • Indirect Stakeholders - Developers, Regulatory Authorities, Domain experts etc.

• Other Actors who are not stakeholders - Project Manager, Requirements Analyst, Software Engineer

RE Process Model

• Elicitation
• Analysis
• Specification
• Validation
• All the activities in the model will produce artifacts that will comprise the set of requirement documents.

• RE takes as input: Stakeholder needs, User Goals, Existing System Information, Domain Information, External and Internal Regulations
• and produces as output: Set of agreed upon input, User Requirements Specification, System Requirements Specification, User/System Models.

Types of RE Projects and Requirements

• The source of requirements can from the customer, the market, a combination of both, or user driven.
• Also on the nature of the project - COTS, bespoke, product line, new or upgrade.
• Depending on the need, requirements can serve as :
  • As a statement of problem to be solved.
  • As a contract between customer and developers.
  • As a means of communication between designers and end-users.
  • As supporting documents for system validation and evolution.