Unit 2 Requirement Elicitation, Analysis, and Specification.pptx
- 1. Component Assembly Model Component Assembly Model is just like the Prototype model, in which first a prototype is created according to the requirements of the customer and sent to the user for evaluation to get the feedback for the modifications to be made and the same procedure is repeated until the software will cater the need of businesses and consumers is realized. Thus it is also an iterative development model. Component Assembly model has been developed to answer the problems faced during the Software Development Life Cycle (SDLC). Instead of searching for different codes and languages, the developers using this model opt for the available components and use them to make an efficient program. Component Assembly Model is an iterative development model that works like the Prototype model and keeps developing a prototype on the basis of the user feedback until the prototype resembles the specifications provided by the customer and the business.
- 2. Moreover, Component Assembly model resembles to the Rapid Application Development (RAD) model and uses the available resources and GUIs to create a software program. Today, a number of SDKs are available that makes it easier for the developers to design a program using less number of codes with the help of SDK. This method has ample of time to concentrate on the other components of the program apart from the coding language, user input and graphical interaction of both user and software program.
- 3. In addition to that, a Component Assembly Model uses a number of previously made components and does not need the use of SDK for creating a program but puts the powerful components together to develop an effective an efficient program. Thus, this is one of the most beneficial advantages of component assembly model as it saves lots of time during the software development program. The developers only need to know the requirements of the customer, look for the useful components that are useful for answering the need of the customer and finally put them together to build a program.
- 4. Functional Requirements Functional requirements define a function that a system or system element must be qualified to perform and must be documented in different forms. The functional requirements describe the behavior of the system as it correlates to the system's functionality. Functional requirements should be written in a simple language, so that it is easily understandable. The examples of functional requirements are authentication, business rules, audit tracking, certification requirements, transaction corrections, etc. • These requirements allow us to verify whether the application provides all functionalities mentioned in the application's functional requirements. They support tasks, activities, user goals for easier project management. • There are a numbers of ways to prepare functional requirements. The most common way is that they are documented in the text form. Other formats of preparing the functional requirements are use cases, models, prototypes, user stories, and diagrams.
- 5. Non-functional requirements Non-functional requirements are not related to the software's functional aspect. They can be the necessities that specify the criteria that can be used to decide the operation instead of specific behaviors of the system. Basic non-functional requirements are - usability, reliability, security, storage, cost, flexibility, configuration, performance, legal or regulatory requirements, etc. They are divided into two main categories: • Execution qualities like security and usability, which are observable at run time. • Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the static structure of the software system. Non-functional requirements specify the software's quality attribute. These requirements define the general characteristics, behaviour of the system, and features that affect the experience of the user. They ensure a better user experience, minimizes the cost factor. Non-functional requirements ensure that the software system must follow the legal and adherence rules. The impact of the non-functional requirements is not on the functionality of the system, but they impact how it will perform. For a well- performing product, atleast some of the non-functional requirements should be met.
- 6. Functional requirements v/s Non-functional requirements
- 8. Unit -2 Requirement Elicitation, Analysis, and Specification
- 9. The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view. Requirement Engineering :- 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. Requirement Engineering Process :- • It is a four step process, which includes – • Feasibility Study • Requirement Gathering • Software Requirement Specification • Software Requirement Validation
- 10. When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop. This feasibility study is focused towards goal of the organization. This study 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. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability. The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken. Feasibility study
- 11. If the feasibility report is positive towards undertaking the project, 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. Requirement Gathering
- 12. 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. The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team. 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 for DFDs etc.
- 13. Software Requirement Validation After 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. This results in huge increase in cost if not nipped in the bud. 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
- 14. Requirement Elicitation Process Requirement elicitation process can be depicted using the following diagram: • 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. • The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably. • Documentation - All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.
- 15. Requirement Elicitation Techniques Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development. There are various ways to discover requirements Interviews :- Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as: • Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly. • Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased. • Oral interviews • Written interviews • One-to-one interviews which are held between two persons across the table. • Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved.
- 16. Surveys :- Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system. Questionnaires :- A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled. A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended. Task analysis :- Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected.
- 17. Domain Analysis :- Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements. Brainstorming :- An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. Prototyping :- 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. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering. Observation :- Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed systems. 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.
- 18. Software Requirements Characteristics Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined. A complete Software Requirement Specifications must be: • Clear • Correct • Consistent • Coherent • Comprehensible • Modifiable • Verifiable • Prioritized • Unambiguous • Traceable • Credible source
- 19. Software Requirements We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system. Broadly software requirements should be categorized in two categories: Functional Requirements Requirements, which are related to functional aspect of software fall into this category. They define functions and functionality within and from the software system. 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.
- 20. Non-Functional Requirements Requirements, which are not related to functional aspect of software, fall into this category. They are implicit or expected characteristics of software, which users make assumption of. Non-functional requirements include - • Security • Logging • Storage • Configuration • Performance • Cost • Interoperability • Flexibility • Disaster recovery • Accessibility
- 21. Requirements are categorized logically as Must Have : Software cannot be said operational without them. Should have : Enhancing the functionality of software. Could have : Software can still properly function with these requirements. Wish list : These requirements do not map to any objectives of software. While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.
- 22. User Interface requirements UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is - • easy to operate • quick in response • effectively handling operational errors • providing simple yet consistent user interface
- 23. User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below – • Content presentation • Easy Navigation • Simple interface • Responsive • Consistent UI elements • Feedback mechanism • Default settings • Purposeful layout • Strategical use of color and texture. • Provide help information • User centric approach • Group based view settings.
- 24. Software System Analyst System analyst in an IT organization is a person, who analyzes the requirement of proposed system and ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the developed software meets the requirements of the client. System Analysts have the following responsibilities: • Analyzing and understanding requirements of intended software • Understanding how the project will contribute in the organization objectives • Identify sources of requirement • Validation of requirement • Develop and implement requirement management plan • Documentation of business, technical, process and product requirements • Coordination with clients to prioritize requirements and remove and ambiguity • Finalizing acceptance criteria with client and other stakeholders
- 48. Difference Between Function Oriented Design and Object Oriented Design COMPARISON FACTORS FUNCTION ORIENTED DESIGN OBJECT ORIENTED DESIGN Abstraction The basic abstractions, which are given to the user, are real world functions. The basic abstractions are not the real-world functions but are the data abstraction where the real- world entities are represented. Function Functions are grouped together by which a higher- level function is obtained. Function are grouped together on the basis of the data they operate since the classes are associated with their methods. execute carried out using structured analysis and structured design i.e, data flow diagram Carried out using UML State information In this approach the state information is often represented in a centralized shared memory. In this approach the state information is not represented in a centralized memory but is implemented or distributed among the objects of the system. Approach It is a top-down approach. It is a bottom-up approach. Begins basis Begins by considering the use case diagrams and the scenarios. Begins by identifying objects and classes. Decompose In function-oriented design we decompose in function/procedure level. We decompose in class level. Use This approach is mainly used for computation sensitive application. This approach is mainly used for evolving system which mimics a business or business case.
- 49. Object-Oriented Analysis and Design(OOAD) Object-Oriented Analysis and Design (OOAD) is a way to design software by thinking of everything as objects similar to real-life things. In OOAD, we first understand what the system needs to do, then identify key objects, and finally decide how these objects will work together. This approach helps make software easier to manage, reuse, and grow. OOAD is based on the concepts of object-oriented programming (OOP) and is an organized and systematic approach to designing and developing software systems. It is a software engineering paradigm that integrates two distinct but closely related processes: Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD). Important Aspects of OOAD Below are some important aspects of OOAD: Object-Oriented Programming: In this the real-world items are represented/mapped as software objects with attributes and methods that relate to their actions. Design Patterns: Design patterns are used by OOAD to help developers in building software systems that are more efficient and maintainable. UML Diagrams: UML diagrams are used in OOAD to represent the different components and interactions of a software system. Use Cases: OOAD uses use cases to help developers understand the requirements of a system and to design software systems that meet those requirements.
- 50. Object-Oriented Analysis Object-Oriented Analysis (OOA) is the process of understanding and analyzing the system requirements by looking at the problem scenario in terms of objects. These objects represent real-world entities or concepts that are relevant to the system being developed. During OOA, the goal is to identify the objects, their attributes, behaviors, and relationships, without focusing on how the system will be implemented. For example: Lets say you’re building a game: • OOA helps you figure out all the things you need to know about the game world – the characters, their features, and how they interact. • It’s like making a map of everything important. • OOA also helps you understand what your game characters will do. It’s like writing down a script for each character. • Every program has specific tasks or jobs it needs to do. OOA helps you list and describe these jobs. OOA is smart about breaking things into different parts. It splits the job into three categories: things your game knows, things your game does, and how things in your game behave.
- 51. Object-Oriented Design Key Principles of OOD A number of fundamental principles support object-oriented design (OOD), helping in the development of reliable, expandable, and maintainable systems: Encapsulation: Bundling data with methods that operate on the data, restricting direct access to some components and protecting object integrity. Abstraction: Simplifying complex systems by modeling classes appropriate to the problem domain, highlighting essential features while hiding unnecessary details. Inheritance: Establishing a hierarchy between classes, allowing derived classes to inherit properties and behaviors from base classes, promoting code reuse and extension. Polymorphism: Enabling objects to be treated as instances of their parent class, allowing one interface to be used for a general class of actions, improving flexibility and integration. Composition: Building complex objects by combining simpler ones, promoting reuse and flexible designs.