Software Requirements Engineering

SE 110

SE 110 Spring 2013

Dilbert on requirements

SE 110 Spring 2013

System Engineering
System engineering focuses on all the entities that are needed to analyze, design and organize various elements that can constitute a product, a service or a technology built for a purpose.
Product engineering focuses on building products. Business process engineering focuses on a business enterprise.
SE 110 Spring 2013

Typical elements of a system

Typical constituents of a system:
Software: Programs, data structures, documentation Hardware: All Electronic devices People: Users and operators Database: Information that software operates on Documentation: Manuals, web sites, on-line help
SE 110 Spring 2013

System Engineering
System is built by starting with high-level assumptions and refining at every step till the required levels of details are achieved.
Customer needs are transformed into a model that includes typical elements mentioned in the previous slide.

System modeling and simulation is done to capture and understand the system at various levels. Various assumptions are made towards constructing a system model.
Simplifications, limitations, constraints (known and unknown), preferences.

SE 110 Spring 2013

Systems Requirements
Customer funded project: Typically, requirements are provided by the customer or are worked out jointly with the customer. Product for the market: Requirements are captured by
Market study and analysis to identify gaps Voice of customer surveys These lead to Market Requirements Document, which in turn, is refined to create the Systems Requirements Document.
SE 110 Spring 2013

Systems Engineering to S/W Engineering Systems requirements document, in turn, is refined with appropriate stakeholders to create:
Product requirements specification System requirements specification Functional requirements specification Hardware requirements specification Software requirements specification
SE 110 Spring 2013

Requirements Engineering
Requirements engineering is the systematic use of proven principles, techniques, languages and tools for the cost effective analysis, documentation and on-going evolution of user needs and the specification of the external behavior of the system to satisfy those needs.

SE 110 Spring 2013

Requirements Engineering
Requirements engineering provides the appropriate mechanism for
Understanding customers needs Assessing feasibility Negotiating a reasonable solution Specifying the solution unambiguously Validating the specification Managing the requirements as they are transformed into an operational system
SE 110 Spring 2013

Requirements Engineering
Requirements Engineering process can be described in the following distinct steps:
Requirements elicitation Requirements specification Requirements analysis and negotiation Requirements validation Requirements management

SE 110 Spring 2013

Requirements Elicitation: Process

Prescribed guidelines:
Identify one or more elicitation methods Assess the business and technical feasibility of the proposed system Identify key people who will be helpful Identify domain constraints related to the system like its operating environment, external system dependencies etc. Create usage scenarios that will help stakeholders to identify key requirements
SE 110 Spring 2013

Requirements Elicitation: Work products

The end products of requirements elicitation step typically are:
A statement of need and feasibility Scope of the system A description of systems technical environment A list of requirements, typically organized in an appropriate way Usage scenarios that provide insight into the system or product Prototypes highlighting features of key requirements

SE 110 Spring 2013

Requirements specification
Requirements are specified typically as a written document, a graphical model, a mathematical model, a collection of usage scenarios, a prototype or a combination of these. Includes various kinds of specification:
System/Product/Software/Hardware/Function al/Usage Requirements specification
SE 110 Spring 2013

Requirements analysis: Questions

The following questions are asked and answered:
Is each requirement consistent with the overall objective of the system? Have all requirements been specified at an appropriate level of abstraction/refinement (based on the document that they belong to)? Is the requirement really critical, or it is a mayhave kind of requirement or does it represent an add-on feature?
SE 110 Spring 2013

Requirements analysis: problems

Contradictions: Requirements that are at variance with each other.
Typically separated from each other and difficult to detect.

Ambiguity: Requirements that can be interpreted in a number of ways. Incompleteness: Not enough details are specified, may result in design missing or interpreting certain features. Mixed levels of abstraction: Abstract requirements are mixed with requirements that are at much lower level of detail.
SE 110 Spring 2013

Requirements analysis: Results

Completion of requirements analysis typically results in base lining of requirements. Results in appropriate specification document.
Inter-related requirements are identified and their relationship noted. Criticality of each requirement is specified.
SE 110 Spring 2013

Requirements validation: Questions

Typical questions:
Is the requirement stated such that it aids in easy translation into the next level work products? Are the requirements traceable to any system model/prototype that has been created? Do the requirements have any technology or domain or application constraints? Are the requirements testable?
SE 110 Spring 2013

Requirements validation: Process

Typically done through a formal review that includes all involved stakeholders
System engineers, marketing teams, customers, users

Several rounds of reviews are conducted, checklists are involved. Several tools are available to aid in such activities.
SE 110 Spring 2013

Requirements management
Requirements management is a set of activities that help the project team to identify, control and track requirements and changes to requirements at any time as the project proceeds.
Requirements Traceability is the ability to follow the life of a requirement, in both forward and backward directions.

Requirements Traceability Matrix (RTM) maintains data regarding the status of the requirement from its origin, through the phases of development including design, coding, testing and maintenance.
SE 110 Spring 2013

RTM: Sample

SE 110 Spring 2013

 How does one arrive at various sets of requirements (product/software/hardware/) from the high-level requirements?

SE 110 Spring 2013

Quality Function Deployment (QFD)

Quality function deployment is a quality management technique that translates the needs of the customer into technical requirements of software.
Voice of customer translated into voice of engineer.

Three main goals:

Prioritize spoken and unspoken customer wants and needs. Translate these needs into technical characteristics and specifications. Build and deliver a quality product or service by focusing everyone towards customer satisfaction.
SE 110 Spring 2013

QFD Process
There are four phases: Each of the four phases uses a matrix.
Phase 1, Product planning: Building the house of quality. This phase documents customer requirements, competitive opportunities, product measurements, competing product measures and the technical ability of the organization to meet each customer requirement.
SE 110 Spring 2013

QFD: Process
Phase 2, Product design: Product concepts are created during this phase and detailed specifications are documented. Phase 3, Process planning: Target values to be achieved are documented and a process is arrived at. Phase 4, Process control: Indicators to monitor further development, maintenance schedules and skills training are planned.
SE 110 Spring 2013

House of Quality

SE 110 Spring 2013

House of quality: Steps

Step 1- Customer Requirements: Voice of customer

Step 2- Regulatory Requirements: Requirements dictated by the Management and regulatory standards
SE 110 Spring 2013

House of quality: Steps

Step 3 - Customer Importance Ratings: Customers rate the Importance of each requirements as per a specific scale.

SE 110 Spring 2013

House of quality: Steps

Step 4 Customer rating of competition: Customers rate the product or service to be developed in relation to the competition.

SE 110 Spring 2013

House of quality: Steps

Step 5 Technical descriptors: Technical descriptors are attributes about the product or service that can be measured or benchmarked against the competition.

SE 110 Spring 2013

House of quality: Steps

Step 6 Direction of improvement: A decision regarding the direction of improvement for each descriptor is made.

SE 110 Spring 2013

House of quality: Steps

Step 7 Relationship matrix: This is where the team determines the relationship between customer needs and the companys ability to meet those needs. Relationships are typically determined as per some scale.

SE 110 Spring 2013

House of quality: Steps

Step 8 Organizational Difficulty: Design attributes are rated in terms of organizational difficulty in this step.

SE 110 Spring 2013

House of Quality: Steps

Step 9 Technical Analysis of Competitor Products: Done by the engineering team, to better understand the competition.

SE 110 Spring 2013

House of quality: Steps

Step 10 Target values for technical descriptors: In this step, target values are established for each technical descriptor.

SE 110 Spring 2013

House of quality: Steps

Step 11 Correlation matrix: In this step, the technical descriptors are compared to check for any negative relationships and contradictions.

SE 110 Spring 2013

House of quality: Steps

Step 12 Absolute importance: In this step, the absolute importance of each technical descriptor is calculated as the product of various parameters available till now.

SE 110 Spring 2013

House of quality
One formal methodology to record technical requirements and competition data from initial requirements. Steps and notations to arrive at the various details can vary.

SE 110 Spring 2013