SlideShare a Scribd company logo

Software Engineering- Requirement Elicitation and Specification

•Download as PPTX, PDF•
•
Nishu Rastogi
Nishu Rastogi

The document discusses the process of requirements engineering for software development. It involves four main steps: 1) Feasibility study to determine if the project is possible. 2) Requirements gathering by communicating with clients and users to understand what the software should do. 3) Creating a software requirements specification (SRS) document that defines system functions and constraints. 4) Validating requirements to ensure they are clear, consistent, and can be implemented.

Related slideshows

Introduction to Software Project Management
Introduction to Software Project ManagementIntroduction to Software Project Management
Introduction to Software Project Management
 
Software design
Software designSoftware design
Software design
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
 
1 of 28
Presentation By Nishu Rastogi Assistant Professor Invertis University, Bareilly 1
• Features of system or system function used to fulfill system purpose • Focus on customer’s needs and problem, not on solutions Types of Requirements- • User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. • System requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. 2
• The process to gather the software requirements from client, analyze and document them is known as requirement engineering. • The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document. 3
It is a four step process, which includes – • Feasibility Study • Requirement Gathering / Elicitation • Software Requirement Specification • Software Requirement Validation 4
• When the client approaches the organization with rough idea about what functions the software must perform • Analysts does a detailed study about whether the desired system and its functionality are feasible to develop • Analyzes whether the software can be practically materialized in terms of implementation, cost constraints and as per values and objectives of the organization • Output of this phase is a feasibility study report that contain comments and recommendations for management about whether or not the project should be undertaken. 5
• If the feasibility report is positive towards undertaking the project then the next phase starts with gathering requirements from the user. • Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include. • Sometimes known as Requirement gathering. 6
7
• Requirement Gathering- The developers discuss with the client and end users and know their expectations from the software. • Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience. • Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Unrealistic requirements are compromised reasonably. • Documentation - All formal & informal, functional and non-functional requirements are documented 8
1- Interviews • Interviewers should be open-minded, willing to listen to stakeholders. • They should prompt the interviewee with a question or a proposal. 2- Surveys 3- Questionnaires 4- Task analysis Team of engineers and developers may analyze the operation for which the new system is required. 5- Brainstorming- An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. 9
6- Domain Analysis- Every software falls into some domain category. The expert people in the domain can help to analyze general and specific requirements. 7- Prototyping- is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. 8- Observation- Team of experts visit the client’s organization or workplace. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software. 10
When Analyst understands the exact customer requirement. Requirement problems are identified and eliminated. 1- Anomaly - Ambiguity in requirement. Ex- If the temp is high switch off heater (Threshold must be defined). 2- Inconsistency- If requirement contradicts with each other. Ex- Multiple user may need different actions on some particular condition. 3- Incompleteness- When requirements have been overlooked. In that case analyst suggest customer, the features which are missing for consideration 11
• SRS is a document created by system analyst after the requirements are collected from various stakeholders. • Requirements received from client are written in natural language • Defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. • It acts as a formal (legal) document between the client and the service provider. 12
• User Requirements are expressed in natural language. • Technical requirements are expressed in structured language, which is used inside the organization. • Design description should be written in Pseudo code. • Format of Forms and GUI screen prints. • Conditional and mathematical notations for DFDs etc. 13
• Functional Requirement • Non- Functional Requirement • Goal of Implementation 14
Related to functional aspect of software such as input/output, processing and error handling EXAMPLES • Search option given to user to search from various invoices. • User should be able to mail any report to management. • Users can be divided into groups and groups can be given separate rights. • Should comply business rules and administrative functions. • Software is developed keeping downward compatibility intact. 15
• Consider the case of the library management system, where F1 : Search Book function Input : An author’s name Output : Details of the author’s books and the location of these books in the library 16
Implicit or expected characteristics of software, which users make assumption of. • Security • Logging • Storage • Configuration • Performance • Cost • Interoperability • Flexibility • Accessibility 17
• Easy to operate • Quick in response • Effectively handling operational errors • Providing simple yet consistent user interface 18
1- Introduction a- Background b- Overall Description c- Environmental Characteristics * Hardware * Peripherals * People 2- Goals of Implementation 3- Functional Requirements 4- Non-Functional Requirements 5- Behavioral Description a- System States b- Events and Actions 19
• Users, Customers and Marketing Personnel To ensure them the system as described in SRS will meet their needs. • Software Developers To make sure that they develop exactly what is required by the customer. • Test Engineers To ensure that the requirements are understandable from a functionality point of view, so that they can test the software and validate its working. 20
• User Document Writers To ensure that they understand the document well, to be able to write user manuals. • Project Managers To ensure that they can estimate the cost easily as it contains all the information required to plan for the project well. • Maintenance Engineers To understand the functionality of the system. It enables them to determine what modifications to the system’s functionality would be needed for a specific purpose. 21
• Clear (easy to understand) • Correct • Consistent (same everywhere no contradiction) • Coherent (logical) • Comprehensible (user-friendly) • Modifiable • Verifiable (justified) • Prioritized • Unambiguous (not more than one interpretation) • Traceable • Credible source (trusted based on facts) 22
• Without developing the SRS document, the system would not be implemented according to customer needs. • Software developers would not know whether what they are developing is what exactly required by the customer. • Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system. • It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document. 23
• Requirement specifications are developed, the requirements mentioned in this document are validated • User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly Check following- If they can be practically implemented If they are valid and as per functionality and domain of software If there are any ambiguities If they are complete If they can be demonstrated 24
25 Requirement Design Describe what will be delivered Describe how it will be done Primary goal of analysis is UNDERSTANDING Primary goal of design is OPTIMIZATION There is more than one solution There is only one final solution Customer Interested Customer not interested
• What is the problem? • Why is it important to solve the problem? • What are the possible solutions to the problem? • What exactly are the data input to the system and what exactly are the data output by the system? • What are the likely complexities that might arise while solving the problem? • If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be? 26
• A written text that accompanies computer software. It either explains how it operates or how to use it, and may mean different things to people in different roles. Types of documentation • Technical Documentation • User Documentation • Marketing Documentation 27
28

More Related Content

Software Engineering- Requirement Elicitation and Specification

  • 1. Presentation By Nishu Rastogi Assistant Professor Invertis University, Bareilly 1
  • 2. • Features of system or system function used to fulfill system purpose • Focus on customer’s needs and problem, not on solutions Types of Requirements- • User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. • System requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. 2
  • 3. • The process to gather the software requirements from client, analyze and document them is known as requirement engineering. • The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document. 3
  • 4. It is a four step process, which includes – • Feasibility Study • Requirement Gathering / Elicitation • Software Requirement Specification • Software Requirement Validation 4
  • 5. • When the client approaches the organization with rough idea about what functions the software must perform • Analysts does a detailed study about whether the desired system and its functionality are feasible to develop • Analyzes whether the software can be practically materialized in terms of implementation, cost constraints and as per values and objectives of the organization • Output of this phase is a feasibility study report that contain comments and recommendations for management about whether or not the project should be undertaken. 5
  • 6. • If the feasibility report is positive towards undertaking the project then the next phase starts with gathering requirements from the user. • Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include. • Sometimes known as Requirement gathering. 6
  • 7. 7
  • 8. • Requirement Gathering- The developers discuss with the client and end users and know their expectations from the software. • Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience. • Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Unrealistic requirements are compromised reasonably. • Documentation - All formal & informal, functional and non-functional requirements are documented 8
  • 9. 1- Interviews • Interviewers should be open-minded, willing to listen to stakeholders. • They should prompt the interviewee with a question or a proposal. 2- Surveys 3- Questionnaires 4- Task analysis Team of engineers and developers may analyze the operation for which the new system is required. 5- Brainstorming- An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. 9
  • 10. 6- Domain Analysis- Every software falls into some domain category. The expert people in the domain can help to analyze general and specific requirements. 7- Prototyping- is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. 8- Observation- Team of experts visit the client’s organization or workplace. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software. 10
  • 11. When Analyst understands the exact customer requirement. Requirement problems are identified and eliminated. 1- Anomaly - Ambiguity in requirement. Ex- If the temp is high switch off heater (Threshold must be defined). 2- Inconsistency- If requirement contradicts with each other. Ex- Multiple user may need different actions on some particular condition. 3- Incompleteness- When requirements have been overlooked. In that case analyst suggest customer, the features which are missing for consideration 11
  • 12. • SRS is a document created by system analyst after the requirements are collected from various stakeholders. • Requirements received from client are written in natural language • Defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. • It acts as a formal (legal) document between the client and the service provider. 12
  • 13. • User Requirements are expressed in natural language. • Technical requirements are expressed in structured language, which is used inside the organization. • Design description should be written in Pseudo code. • Format of Forms and GUI screen prints. • Conditional and mathematical notations for DFDs etc. 13
  • 14. • Functional Requirement • Non- Functional Requirement • Goal of Implementation 14
  • 15. Related to functional aspect of software such as input/output, processing and error handling EXAMPLES • Search option given to user to search from various invoices. • User should be able to mail any report to management. • Users can be divided into groups and groups can be given separate rights. • Should comply business rules and administrative functions. • Software is developed keeping downward compatibility intact. 15
  • 16. • Consider the case of the library management system, where F1 : Search Book function Input : An author’s name Output : Details of the author’s books and the location of these books in the library 16
  • 17. Implicit or expected characteristics of software, which users make assumption of. • Security • Logging • Storage • Configuration • Performance • Cost • Interoperability • Flexibility • Accessibility 17
  • 18. • Easy to operate • Quick in response • Effectively handling operational errors • Providing simple yet consistent user interface 18
  • 19. 1- Introduction a- Background b- Overall Description c- Environmental Characteristics * Hardware * Peripherals * People 2- Goals of Implementation 3- Functional Requirements 4- Non-Functional Requirements 5- Behavioral Description a- System States b- Events and Actions 19
  • 20. • Users, Customers and Marketing Personnel To ensure them the system as described in SRS will meet their needs. • Software Developers To make sure that they develop exactly what is required by the customer. • Test Engineers To ensure that the requirements are understandable from a functionality point of view, so that they can test the software and validate its working. 20
  • 21. • User Document Writers To ensure that they understand the document well, to be able to write user manuals. • Project Managers To ensure that they can estimate the cost easily as it contains all the information required to plan for the project well. • Maintenance Engineers To understand the functionality of the system. It enables them to determine what modifications to the system’s functionality would be needed for a specific purpose. 21
  • 22. • Clear (easy to understand) • Correct • Consistent (same everywhere no contradiction) • Coherent (logical) • Comprehensible (user-friendly) • Modifiable • Verifiable (justified) • Prioritized • Unambiguous (not more than one interpretation) • Traceable • Credible source (trusted based on facts) 22
  • 23. • Without developing the SRS document, the system would not be implemented according to customer needs. • Software developers would not know whether what they are developing is what exactly required by the customer. • Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system. • It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document. 23
  • 24. • Requirement specifications are developed, the requirements mentioned in this document are validated • User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly Check following- If they can be practically implemented If they are valid and as per functionality and domain of software If there are any ambiguities If they are complete If they can be demonstrated 24
  • 25. 25 Requirement Design Describe what will be delivered Describe how it will be done Primary goal of analysis is UNDERSTANDING Primary goal of design is OPTIMIZATION There is more than one solution There is only one final solution Customer Interested Customer not interested
  • 26. • What is the problem? • Why is it important to solve the problem? • What are the possible solutions to the problem? • What exactly are the data input to the system and what exactly are the data output by the system? • What are the likely complexities that might arise while solving the problem? • If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be? 26
  • 27. • A written text that accompanies computer software. It either explains how it operates or how to use it, and may mean different things to people in different roles. Types of documentation • Technical Documentation • User Documentation • Marketing Documentation 27
  • 28. 28