Software Requirements Engineering

Classified in Other subjects

Written at on English with a size of 3.91 KB.

Functional vs. Non-Functional Requirements

Functional Requirements define functionality for users, using natural language.

Non-Functional Requirements define quality attributes such as:

  • Usability
  • Reliability
  • Efficiency & Performance
  • Hardware & Software Constraints


Requirements state what software does, not how it does it; this avoids unnecessary constraints.

Design Patterns

A design pattern is a reusable solution to a recurring problem.

Types of Requirements

  • Business Requirements: High-level, describe business objectives, and do not describe functionality.
  • User Requirements: Describe the tasks users need to accomplish. Multiple user requirements may relate to one business requirement.
  • Software Features: Groups of logically related functional requirements, often with a marketing emphasis, organized hierarchically (e.g., in a tree structure).

Properties of Good Requirements

Good requirements are:

  • Complete
  • Correct
  • Feasible
  • Unambiguous
  • Consistent
  • Validatable
  • Modifiable
  • Traceable

Requirements Engineering Process

  1. Eliciting Needs
  2. Analyzing Information & Specifications
  3. Allocating Requirements
  4. Negotiating Implementation Planning
  5. Documenting Requirements
  6. Reviewing Documents for Validation

Information Gathering Techniques

  • Interviews
  • Document Analysis
  • Surveys
  • Problem Lists
  • Customer Site Visits
  • Reverse Engineering Existing Systems
  • Facilitated Requirements Workshops

Use Cases

A use case is a set of related usage scenarios, a sequence of interactions between the system and an actor.

User Stories

Used in agile development, user stories provide a short description of a requirement and are not expanded into detailed functional requirements.

Requirements Management Activities

  • Define a requirements change-control process.
  • Establish change board control.
  • Use a requirements management tool.
  • Create a traceability matrix.
  • Track the status of each requirement.
  • Establish baselines and control versions of requirements documents.
  • Maintain a history of requirements.


Inspections involve developers reviewing documents to find errors, ambiguity, and violations.

Inspection Roles

  • Author: The main developer.
  • Inspectors: Reviewers of the document.
  • Recorder: Documents the findings.
  • Moderator: Facilitates the inspection meeting.
  • Manager: Responsible for the inspection process (but not present during the inspection itself).

Inspection Rules

: manager not present,inspectors take turns&tactful,problems not solved,producer does not defend work

Req B.O.R: expect analysts to speak ur language, expect analyst to learn about ur business&obj, expect analyst to structure the info u provided in rs, have analyst explain all work products of req, devs treat u with respect, dev&analysts provide ideas, describe chars of product, given opportunity to adjust reqs, receive good faith estimates of costs when change is requested, receive a system that meets ur needs 
Customer B.O.R: educate dev&analysts about ur business, spend time to clarify reqs, be specific about reqs, make timely decisions about reqs, respect devs, set priorities of func reqs, review req docs and evaluate prototypes, communicate changes to reqs, follow dev organizational process, respect analyst's use of req engr process

Entradas relacionadas: