Requirement Engineering. Types of requirement

This content is fosussing on REquirement Engineering.
Types of requirement, fours phases of requirement enginnering, SRS, IEEE statndards for SRS.

1. Module-2 Requirement Engineering Mr. Deepak V Ulape. (Assistant Professor) (8793536185)

2. 2.1 Requirement Engineering 2.1.1 Types of Requirements – Functional and Nonfunctional 2 .1.2 Four Phases of Requirement Engineering 2.1.3 Software requirement Specification (SRS) 2.2.4 Structure and contents of SRS 2.1.5 IEEE standard format for SRS

3. 2.1.1 Types of Requirements – Functional and Nonfunctional 1. Functional Requirements Definition : Functional requirements describe what the software should do. They define the functions or features that the system must have. Examples : User Authentication : The system must allow users to log in using a username and password. Search Functionality : The software should enable users to search for products by name or category. Report Generation : The system should be able to generate sales reports for a specified date range. Explanation : Functional requirements specify the actions that the software needs to perform. These are the basic features and functionalities that users expect from the software.

4. 2. Non-functional Requirements Definition : Non-functional requirements describe how the software performs a task rather than what it should do. They define the quality attributes, performance criteria, and constraints. Examples : Performance : The system should process 1,000 transactions per second. Usability : The software should be easy to use and have a user-friendly interface. Reliability : The system must have 99.9% uptime. Security : Data must be encrypted during transmission and storage. Explanation : Non-functional requirements are about the system’s behavior, quality, and constraints. They ensure that the software meets certain standards of performance, usability, reliability, and security.

5. Four Phases of Requirement Engineering

6. 1. Feasibility Study A feasibility study is an assessment of the practicality of a proposed plan or project. It analyzes the viability of the project to determine whether it is likely to succeed and identifies potential issues and problems that could arise during its execution

7. Feasibility Study types: Technical Feasibility : In Technical Feasibility current resources both hardware software along required technology are analyzed/assessed to develop the project. This technical feasibility study reports whether there are correct required resources and technologies that will be used for project development. Along with this, the feasibility study also analyzes the technical skills and capabilities of the technical team, whether existing technology can be used or not, whether maintenance and up-gradation are easy or not for the chosen technology, etc. Operational Feasibility:  In Operational Feasibility degree of providing service to requirements is analyzed along with how easy the product will be to operate and maintain after deployment. Along with this other operational scopes are determining the usability of the product, Determining suggested solution by the software development team is acceptable or not, etc.  Economic Feasibility:  In the Economic Feasibility study cost and benefit of the project are analyzed. This means under this feasibility study a detailed analysis is carried out will be cost of the project for development which includes all required costs for final development hardware and software resources required, design and development costs operational costs, and so on.

8. 2. Requirements Elicitation It is related to the various ways used to gain knowledge about the project domain and requirements. The various sources of domain knowledge include customers, business manuals, the existing software of the same type, standards, and other stakeholders of the project. The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. .  Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage.  Requirements elicitation is the process of gathering information about the needs and expectations of stakeholders for a software system. This is the first step in the requirements engineering process and it is critical to the success of the software development project. The goal of this step is to understand the problem that the software system is intended to solve and the needs and expectations of the stakeholders who will use the system.

9. 3. Requirements Specification This activity is used to produce formal software requirement models. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality. During specification, more knowledge about the problem may be required which can again trigger the elicitation process. The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.  Requirements specification is the process of documenting the requirements identified in the analysis step in a clear, consistent, and unambiguous manner. This step also involves prioritizing and grouping the requirements into manageable chunks. The goal of this step is to create a clear and comprehensive document that describes the requirements for the software system. This document should be understandable by both the development team and the stakeholders.

10. 4. Requirements Verification and Validation Verification:  It refers to the set of tasks that ensures that the software correctly implements a specific function.  Validation:  It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework. The main steps for this process include: The requirements should be consistent with all the other requirements i.e. no two requirements should conflict with each other. The requirements should be complete in every sense. The requirements should be practically achievable.

11. Software Requirement Specification (SRS) Software Requirement Specification (SRS) Format  as the name suggests, is a complete specification and description of requirements of the software that need to be fulfilled for the successful development of the software system. These requirements can be functional as well as non-functional depending upon the type of requirement. The interaction between different customers and contractors is done because it is necessary to fully understand the needs of customers.

12. Introduction Purpose of this Document –  At first, main aim of why this document is necessary and what’s purpose of document is explained and described. Scope of this document –  In this, overall working and main objective of document and what value it will provide to customer is described and explained. It also includes a description of development cost and time required. Overview –  In this, description of product is explained. It’s simply summary or overall review of product. General description In this, general functions of product which includes objective of user, a user characteristic, features, benefits, about why its importance is mentioned. It also describes features of user community.

13. Functional Requirements In this, possible outcome of software system which includes effects due to operation of program is fully explained. All functional requirements which may include calculations, data processing, etc. are placed in a ranked order. Functional requirements specify the expected behavior of the system-which outputs should be produced from the given inputs. They describe the relationship between the input and output of the system. For each functional requirement, detailed description all the data inputs and their source, the units of measure, and the range of valid inputs must be specified. Interface Requirements In this, software interfaces which mean how software program communicates with each other or users either in form of any language, code, or message are fully described and explained. Examples can be shared memory, data streams, etc. Performance Requirements In this, how a software system performs desired functions under specific condition is explained. It also explains required time, required memory, maximum error rate, etc. The performance requirements part of an SRS specifies the performance constraints on the software system. All the requirements relating to the performance characteristics of the system must be clearly specified. There are two types of performance requirements: static and dynamic. Static requirements are those that do not impose constraint on the execution characteristics of the system. Dynamic requirements specify constraints on the execution behaviour of the system.

14. Design Constraints In this, constraints which simply means limitation or restriction are specified and explained for design team. Examples may include use of a particular algorithm, hardware and software limitations, etc. There are a number of factors in the client’s environment that may restrict the choices of a designer leading to design constraints such factors include standards that must be followed resource limits, operating environment, reliability and security requirements and policies that may have an impact on the design of the system. An SRS should identify and specify all such constraints.

15. Non-Functional Attributes In this, non-functional attributes are explained that are required by software system for better performance. An example may include Security, Portability, Reliability, Reusability, Application compatibility, Data integrity, Scalability capacity, etc. Preliminary Schedule and Budget In this, initial version and budget of project plan are explained which include overall time duration required and overall cost required for development of project. Appendices In this, additional information like references from where information is gathered, definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.

16. Uses of SRS document Development team require it for developing product according to the need. Test plans are generated by testing group based on the describe external behaviour . Maintenance and support staff need it to understand what the software product is supposed to do. Project manager base their plans and estimates of schedule, effort and resources on it. customer rely on it to know that product they can expect. As a contract between developer and customer. in documentation purpose.

17. IEEE standard format for SRS The IEEE (Institute of Electrical and Electronics Engineers) standard for Software Requirements Specifications (SRS) is defined in IEEE 830-1998, titled "IEEE Recommended Practice for Software Requirements Specifications." This standard provides a structured approach to documenting the requirements for a software system. 1. Introduction - 1.1 Purpose: Defines the purpose of the SRS and the intended audience. - 1.2 Scope: Outlines the software product to be specified, including its boundaries, major features, and goals. - 1.3 Definitions, Acronyms, and Abbreviations: Provides definitions for terms, acronyms, and abbreviations used in the SRS. - 1.4 References: Lists any references to other documents or standards that are pertinent to the SRS. - 1.5 Overview: Gives an overview of the remaining sections of the SRS.

18. 2. Overall Description - 2.1 Product Perspective: Describes the context and origin of the product, including its relationship to other systems. - 2.2 Product Functions: Provides a high-level summary of the software’s functions. - 2.3 User Classes and Characteristics: Identifies the different user types and their needs. - 2.4 Operating Environment: Specifies the hardware, software, and other environmental constraints. - 2.5 Design and Implementation Constraints: Lists any constraints on design and implementation. - 2.6 User Documentation: Details the documentation and training materials provided to users. - 2.7 Assumptions and Dependencies: Describes any assumptions and dependencies that could impact the software requirements.

19. 3. Specific Requirements - 3.1 Functional Requirements : Provides detailed descriptions of the functions the software must perform. - 3.2 External Interface Requirements: Details interactions between the software and other systems or users. - 3.2.1 User Interfaces: Specifies the user interface requirements. - 3.2.2 Hardware Interfaces: Describes the hardware interfaces if applicable. - 3.2.3 Software Interfaces: Outlines any software interfaces. - 3.2.4 Communications Interfaces: Defines the communication protocols and standards. - 3.3 Performance Requirements: Specifies performance constraints and criteria. - 3.4 Design Constraints: Describes constraints related to the design of the software. - 3.5 Software System Attributes: Details attributes such as reliability, availability, security, and maintainability. - 3.6 Other Requirements: Includes any other requirements not covered in the above sections.

20. 4. Appendices - 4.1 Glossary: Provides a glossary of terms used in the SRS. - 4.2 Analysis Models: Includes diagrams and models that support the requirements, such as data flow diagrams or use case diagrams. - 4.3 Issue Tracking: Optional section for tracking unresolved issues or changes.

21. Introduction to Web Engineering : Web Engineering is a discipline that focuses on the design, development, and maintenance of web applications and systems. It combines principles from computer science, software engineering, and web development to create robust, scalable, and user-friendly web solutions.

22. Agile Methodology The Agile methodology is a project management and software development approach that emphasizes flexibility, collaboration, and customer-centricity. It is the latest model used by major companies today like Facebook, google, amazon, etc. Agile is a  project management  and software development approach that aims to be more effective. It focuses on delivering smaller pieces of work regularly instead of one big launch. This allows teams to adapt to changes quickly and provide customer value faster.

23. Agile methodologies are iterative and incremental, which means it’s known for breaking a project into smaller parts and adjusting to changing requirements. They prioritize flexibility, collaboration, and customer satisfaction. Major companies like Facebook, Google, and Amazon use Agile because of its adaptability and customer-focused approach.

24. Life cycle of Agile Methodology The  Agile software development life cycle  helps you break down each project you take on into six simple stages:

25. 1. Requirement Gathering In this stage, the project team identifies and documents the needs and expectations of various stakeholders, including clients, users, and subject matter experts. It involves defining the  project’s scope , objectives, and requirements. Establishing a budget and schedule. Creating a project plan and allocating resources. 2. Design Developing a high-level system architecture. Creating detailed specifications, which include data structures, algorithms, and interfaces. Planning for the software’s user interface.

26. 3. Development (Coding) Writing the actual code for the software. Conducting unit testing to verify the functionality of individual components. 4. Testing This phase involves several types of testing: Integration Testing:  Ensuring that different components work together. System Testing:  Testing the entire system as a whole. User Acceptance Testing:  Confirming that the software meets user requirements. Performance Testing :  Assessing the system’s speed, scalability, and stability. 5. Deployment Deploying the software to a production environment. Put the software into the real world where people can use it. Make sure it works smoothly in the real world. Providing training and support for end-users.

27. 6. Review (Maintenance) Addressing and resolving any issues that may arise after deployment. Releasing updates and patches to enhance the software and address problems.

28. Adaptive Software Development (ASD) is a  software development methodology  that emphasizes adaptability to respond to changing requirements and environments. It focuses on continuous learning and is considered a part of agile software development. Iterative Development:  ASD breaks down the project into small, manageable iterations, delivering incremental values. Risk Management:  ASD involves identifying and addressing risks early in the development process. Continuous Testing:  It integrates testing throughout the development process to ensure high-quality outcomes. Decentralized Control:  It encourages decision-making at the team level instead of relying on top-down directives. Customer Satisfaction:  It prioritizes customer satisfaction by delivering products that meet their needs and expectations.

29. Characteristics of ASD Process principles of ASD that distinguish it from more traditional, plan-driven methodologies: Adaptability:  ASD focuses on high-level adaptive planning instead of detailed, fixed plans. Collaborative Environment:  In ASD, a strong focus is on collaboration within the team, thus promoting a culture of open communication. Continuous Learning:  It emphasizes learning from each iteration and using feedback to improve the process and the product. Iterative Development:  In ASD, the development is broken into small, manageable increments. Each increment delivers a piece of functional software. Responsive to Change:  It allows the project to quickly adapt to the changes in requirements, technology, and market conditions.

30. Phases of ASD Process ASD life cycle incorporates three phases namely:  Speculation Collaboration Learning These are explained below:

31. 1. Speculation During this phase project is initiated and planning is conducted. The project plan uses project initiation information like project requirements, user needs, customer mission statement, etc , to define a set of release cycles that the project wants.  2. Collaboration It is the difficult part of ASD as it needs the workers to be motivated. It collaborates communication and teamwork but emphasizes individualism as individual creativity plays a major role in creative thinking. People working together must trust each other to   Criticize without animosity, Assist without resentment, Work as hard as possible, Possession of skill set, Communicate problems to find effective solutions.

32. 3. Learning The workers may have an overestimate of their understanding of the technology which may not lead to the desired result. Learning helps the workers to increase their level of understanding of the project.  The learning process is in 3 ways:  Focus groups Technical reviews Project postmortem

33. Strengths of ASD key strengths of Adaptive Software Development (ASD): Customer Focus:  Regular and active involvement of customers to make sure that the product meets their needs and expectations. Continuous Delivery:  Delivering functional software in small, manageable increments allows for early and continuous delivery of value. Early Problem Detection:  Regular testing and releases help to identify and resolve issues early in the development process. Strong Teamwork:  Emphasizes teamwork among the team members, thus fostering a supportive environment.

34. Weakness of ASD weaknesses of Adaptive Software Development (ASD): Requires High Level of Skill:  Successful implementation of ASD requires a team with a high-level of skill, experience, and familiarity with the agile principles. Changing Requirements:  The flexible nature of ASD may result in frequent changes of requirements, which might result in scope creep if it is not managed properly. Customer Availability:  ASD relies heavily on active and continuous customer participation, which can be difficult to achieve in cases when the customer is not fully engaged or not available. Uncertain Project Outcomes:  The iterative and adaptive nature of ASD makes it difficult to predict the outcome of the project.

35. The  Dynamic Systems Development technique (DSDM)  is an associate degree agile code development approach that provides a framework for building and maintaining systems. The DSDM philosophy is borrowed from a modified version of the sociologist principle—80 % of An application is often delivered in twenty percent of the time it’d desire deliver the entire (100 percent) application. DSDM is An iterative code method within which every iteration follows the 80% rule that simply enough work is needed for every increment to facilitate movement to the following increment. The remaining detail is often completed later once a lot of business necessities are noted or changes are requested and accommodated.

36. scrum in software development: Scrum is a management framework that teams use to self-organize tasks and work towards a common goal. It is a framework within which people can address complex adaptive problems while the productivity and creativity of delivering products are at the highest possible value. Scrum is a management framework that teams use to self-organize and work towards a common goal. Scrum allows us to develop products of the highest value while making sure that we maintain creativity and productivity. The iterative and incremental approach used in scrum allows the teams to adapt to the changing requirements.

37. Silent features of Scrum Scrum is a light-weighted framework Scrum emphasizes self-organization Scrum is simple to understand Scrum framework helps the team to work together Lifecycle of Scrum

38. Sprint :  A Sprint is a time box of one month or less. A new Sprint starts immediately after the completion of the previous Sprint.  Release:  When the product is completed, it goes to the Release stage. Sprint Review :  If the product still has some non-achievable features, it will be checked in this stage and then passed to the Sprint Retrospective stage. Sprint Retrospective :  In this stage quality or status of the product is checked.  Product Backlog:  According to the prioritize features the product is organized. Sprint Backlog :  Sprint Backlog is divided into two parts Product assigned features to sprint and Sprint planning meeting.

39. Advantage of Scrum framework Scrum framework is fast moving and money efficient. Scrum framework works by dividing the large product into small sub-products. It’s like a divide and conquer strategy In Scrum customer satisfaction is very important. Scrum is adaptive in nature because it have short sprint. As Scrum framework rely on constant feedback therefore the quality of product increases in less amount of time

40. Disadvantage of Scrum framework : Scrum framework do not allow changes into their sprint. Scrum framework is not fully described model. If you wanna adopt it you need to fill in the framework with your own details like  Extreme Programming(XP),   Kanban ,  Dynamic Systems Development Method (DSDM) . It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear definition. The daily Scrum meetings and frequent reviews require substantial resources.