Software Requirements

1
Software Requirements

• By Jane Cleland-Huang
• Presentation by Donovan Faustino

2
Introduction

• Requirements Engineering - process of eliciting,
  analyzing, validating, and managing requirements
• IEEE standards such as IEEE Std 830-1998 provide
  guidelines for recommended practices

3
Requirements

• Defining Requirements
• property of the system or a constraint placed
  either upon the product itself or upon the
  process by which the system is created. Formally
  IEE Std 610.12.1990 1) A condition or
  capability needed by a user to solve a problem or
  achieve an objective
• 2) A condition or capability that must be met or
  possessed by a system or system component to
  satisfy a contract, standard, specification, or
  other formally imposed documents.
• 3) A documented representation of a condition or
  capability as in (1) or (2).

4
Phases of Requirements

• Elicitation
• Analysis
• Specification
• Management
• Validation

5
Elicitation

• proactively working with stakeholders to discover
  their needs, identify and negotiate potential
  conflicts, and establish a clear scope and
  boundaries for the project

6
Elicitation(cont)

• Understanding the Problem and Its Domain
• Making the business case
• current trends have organizations are no longer
  willing to invest in IT projects unless those
  projects return clear value to the business
• From a requirements perspective, these include a
  lack of clear purpose for the product,
  insufficient stakeholder involvement, lack of
  agreement between stakeholders, rapidly changing
  the requirements, goldplating(adding additional
  and unnecessary features), poor change
  management, and lack of analysis of the
  requirements

7
Elicitation(cont)

• Elicitation techniques
• Collaborative sessions
• Interviewing techniques
• Questionaires
• Ethnography
• Protyping
• Documentation
• Modeling
• Roleplaying
• Checklists of NFRs

8
Elicitation

• Conflict Identification and Negotiation

9
Analysis

• a deeper understanding of the product and its
  interactions, identify requirements, define
  high-level architectural design, allocating req
  to architectural components, and identify
  additional conflicts that merge through
  considering architectural implementations and
  negotiating agreements between stakeholders

10
Analysis(cont)

• Conceptual Modeling
• ML is very well known.
• IEEE Std 1320.1, IDEF0 for functional modeling
  and IEEE Std 1320.2 IDEF1 X97 for information
  modeling.
• Architectural Design and Requirement Allocation
• Architectural quality is measured by its ability
  to fulfill the stated requirements

11
Specification

• documents that capture the system and software
  req. in order to support their systematic review,
  evaluation, and approval. Document that describes
  the system to be developed in a format that can
  be reviewed, evaluated and approved in a
  systematic way.

12
Specification(cont)

• Qualities of an Individual Requirement
• Concise
• Correct
• Nonambiguous
• Feasible
• Verifiable

13
Specification (cont)

• Qualities of the Set of Requirements
• Realistic
• Concise
• Complete
• Consistent

14
Validation

• goes through the other four activities. Ensure
  the system meets stakeholders requirements
  through activities such as formal and informal
  reviews

15
Validation(cont)

• Types of validation
• Reviews
• Prototyping
• Model validation
• Acceptance Tests

16
Management

• starts from the moment the first req is elicited
  and ends only when the system is finally
  decommissioned. requirement management includes
  software configuration management, traceability,
  impact analysis, and version control

17
Management(cont)

• Requirements traceability
• Ability to describe and follow the life of a
  requirement, in both a forward and backward
  direction.
• Change Requests
• Managed systematically
• Requirements attributes

18
Conclusion

• Traditional Method
• Agile Methods

19
My own opinion
20
Validation