P. 1
Requirements Engineering

Requirements Engineering

|Views: 4|Likes:
Published by Surya Pratap Desai

More info:

Published by: Surya Pratap Desai on Apr 30, 2013
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less





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

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

– Customer needs are transformed into a model that includes typical elements mentioned in the previous slide. SE 110 – Spring 2013 . – Simplifications. • System modeling and simulation is done to capture and understand the system at various levels. preferences. constraints (known and unknown). limitations.System Engineering • System is built by starting with high-level assumptions and refining at every step till the required levels of details are achieved. • Various assumptions are made towards constructing a system model.

requirements are provided by the customer or are worked out jointly with the customer.Systems Requirements • Customer funded project: Typically. which in turn. • 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”. is refined to create the “Systems Requirements Document”. SE 110 – Spring 2013 .

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 . in turn.Systems Engineering to S/W Engineering • Systems requirements document.

Requirements Engineering • Requirements engineering is the systematic use of proven principles. 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 . languages and tools for the cost effective analysis. techniques.

Requirements Engineering • Requirements engineering provides the appropriate mechanism for – Understanding customer’s 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 .

– Create usage scenarios that will help stakeholders to identify key requirements SE 110 – Spring 2013 . external system dependencies etc.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.

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 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 system’s technical environment A list of requirements.

Requirements specification • Requirements are specified typically as a written document. a graphical model. 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 . a mathematical model. a collection of usage scenarios.

or it is a mayhave kind of requirement or does it represent an add-on feature? 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.

• Incompleteness: Not enough details are specified. • Mixed levels of abstraction: Abstract requirements are mixed with requirements that are at much lower level of detail. – Typically separated from each other and difficult to detect.Requirements analysis: problems • Contradictions: Requirements that are at variance with each other. may result in design missing or interpreting certain features. SE 110 – Spring 2013 . • Ambiguity: Requirements that can be interpreted in a number of ways.

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

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 .

• Several tools are available to aid in such activities.Requirements validation: Process • Typically done through a formal review that includes all involved stakeholders – System engineers. marketing teams. checklists are involved. users … • Several rounds of reviews are conducted. customers. SE 110 – Spring 2013 .

in both forward and backward directions. SE 110 – Spring 2013 .Requirements management • Requirements management is a set of activities that help the project team to identify. – Requirements Traceability is the ability to follow the life of a requirement. • Requirements Traceability Matrix (RTM) maintains data regarding the status of the requirement from its origin. testing and maintenance. control and track requirements and changes to requirements at any time as the project proceeds. through the phases of development including design. coding.

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 .

SE 110 – Spring 2013 . – Build and deliver a quality product or service by focusing everyone towards customer satisfaction. – Translate these needs into technical characteristics and specifications. • Three main goals: – Prioritize spoken and unspoken customer wants and needs. – Voice of customer translated into voice of engineer.Quality Function Deployment (QFD) • Quality function deployment is a quality management technique that translates the needs of the customer into technical requirements of software.

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

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

House of Quality SE 110 – Spring 2013 .

Regulatory Requirements: Requirements dictated by the Management and regulatory standards SE 110 – Spring 2013 .House of quality: Steps Step 1.Customer Requirements: Voice of customer Step 2.

Customer Importance Ratings: Customers rate the Importance of each requirements as per a specific scale.House of quality: Steps Step 3 . 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 .

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 company’s 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.

to better understand the competition. SE 110 – Spring 2013 .House of Quality: Steps Step 9 – Technical Analysis of Competitor Products: Done by the engineering team.

target values are established for each technical descriptor.House of quality: Steps Step 10 – Target values for technical descriptors: In this step. 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. SE 110 – Spring 2013 . the absolute importance of each technical descriptor is calculated as the product of various parameters available till now.

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

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->