Software requirement & specification .pptx

Software requirement

1. Software Requirements Specification & Analysis Course Code: SE 212 1

2. Course Outline Attendance: 07 Class Test: 15 Assignment: 05 Presentation: 08 Mid Exam: 25 Final Exam: 40 2

3. Software Engineering Software is a program or set of programs containing instructions that provide desired functionality. Engineering is the process of designing and building something that serves a particular purpose and finds a cost-effective solution to problems. Software engineering includes a variety of techniques, tools, and methodologies, including requirements analysis, design, testing, and maintenance. 3

4. Objectives To introduce the concepts of user requirements and system requirements To describe the functional and non-functional requirements To explain how software requirements may be organized in a requirements documents 4

5. Software Requirement It is any kinds of requirements which describes features and functionalities of the desire systems. It is expectations of users from a system It could be hidden or obvious, known or unknown. 5

6. Software Requirement According to IEEE: A condition or capability needed by a user to solve a problem or achieve an objective 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 A documented representation of a condition or capability as in 1 and 2. 6

7. Types of Software Requirement Functional requirements Non-functional requirements Domain requirements 7

8. Functional Requirements It defines what function a system is likely to perform The end user specifically demands as basic facilities that the system should offer. It must be directly in the final product. 8

9. Non-functional Requirements It defines how the system should perform the system priority It extents to which these factors are implemented varies from one project to other.  It ensures Portability. It ensures Security. It ensures Maintainability. It ensures Reliability. It ensures Scalability. Performance Flexibility 9

10. Difference Between Functional and Non-Functional Requirement Functional Requirement Non-Functional Requirement It is mandatory. It is not mandatory. A functional requirement defines a system or its component. A non-functional requirement defines the quality attribute of a software system. Functional requirement is specified by User. Non-functional requirement is specified by technical peoples e.g. Architect, Technical leaders and software developers. Usually easy to define. Usually more difficult to define. It is captured in use case. It is captured as a quality attribute. Defined at a component level. Applied to a system as a whole. 10

11. Domain Requirements Domain requirements are expectations related to a particular type of software, purpose or industry vertical . It can be functional or nonfunctional. 11

12. Other common software requirement User requirements:  These requirements describe what the end-user wants from the software system . System requirements:  These requirements specify the technical characteristics of the software system, such as its architecture, hardware requirements, software components, and interfaces . Regulatory requirements:  These requirements specify the legal or regulatory standards that the software system must meet.  Interface requirements : These requirements specify the interactions between the software system and external systems or components, such as databases, web services, or other software applications. Design requirements:  These requirements describe the technical design of the software system. 12

13. Requirement Engineering The process to gather the software requirements from client, analyze and document them is known as requirement engineering . It is a four step process, which includes – Feasibility Study Requirement Gathering Software Requirement Specification Software Requirement Validation 13

14. Feasibility Study I t comes up with rough idea about what all functions the software must perform It is a detailed study about whether the desired system and its functionality are feasible to develop It focuses towards goal of the organization . It analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization . 14

15. Requirement Gathering 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. 15

16. Software Requirement Specification SRS is a document created by system analyst after the requirements are collected from various stakeholders . SRS 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 . SRS should come up with following features : 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 16

17. Software Requirement Validation Requirements can be checked against following conditions - 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 17

18. Requirement Elicitation Process Requirements 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. Requirements may then be prioritized and reasonably compromised. Documentation -   All formal & informal, functional and non-functional requirements are documented and made available for next phase processing. 18

19. Software Requirements Characteristics A complete Software Requirement Specifications must be: Clear Correct Consistent Coherent Comprehensible Modifiable Verifiable Prioritized Unambiguous Traceable Credible source 19

20. Advantages B etter organization:  Classifying software requirements helps organize them into groups that are easier to manage, prioritize, and track throughout the development process. Improved communication:  Clear classification of requirements makes it easier to communicate them to stakeholders, developers, and other team members. It also ensures that everyone is on the same page about what is required. Increased quality:  By classifying requirements, potential conflicts or gaps can be identified early in the development process. This reduces the risk of errors, omissions, or misunderstandings, leading to higher quality software. Improved traceability:   Classifying requirements helps establish traceability, which is essential for demonstrating compliance with regulatory or quality standards. 20

21. Disadvantages Complexity : Classifying software requirements can be complex, especially if there are many stakeholders with different needs or requirements. It can also be time-consuming to identify and classify all the requirements. Rigid structure: A rigid classification structure may limit the ability to accommodate changes or evolving needs during the development process. It can also lead to a siloed approach that prevents the integration of new ideas or insights. Misclassification: Misclassifying requirements can lead to errors or misunderstandings that can be costly to correct later in the development process. 21