IT1204 - Software Engineering - L4
Download as PPTX, PDF2 likes620 views
The document discusses the importance of requirements engineering in software development, defining various types of requirements such as business, user, and system/software requirements. It emphasizes the challenges in accurately capturing requirements due to ambiguity in natural language and the necessity of conducting a feasibility study before implementing a system. The document also highlights the processes involved in requirements elicitation, analysis, validation, and verification to ensure clarity and consistency in meeting stakeholder needs.
IT1204 - Software Engineering - L4
- 1. Software Engineering L4 Sameera Gunathilaka Lead Software Engineer ERP Technical Consultant IT1204 – Software Engineering Institute of Technology, University of Moratuwa 1
- 2. SDLC – Waterfall Model IT1204 – Software Engineering Institute of Technology, University of Moratuwa 2
- 3. “Requirements” ? The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. IT1204 – Software Engineering Institute of Technology, University of Moratuwa 3
- 4. According to IEEE standard 729, a requirement is.. IT1204 – Software Engineering Institute of Technology, University of Moratuwa 4 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 above two
- 5. Importance of Requirement Specification IT1204 – Software Engineering Institute of Technology, University of Moratuwa 5
- 6. Boundary of two worlds IT1204 – Software Engineering Institute of Technology, University of Moratuwa 6
- 7. Why is it so Hard? IT1204 – Software Engineering Institute of Technology, University of Moratuwa 7 We know why projects fail, we know how to prevent their failures. So why do they still fail? GAP – real world problem vs computer program • Strengths of a requirement • Must/Shall • Should • Will
- 8. Building the right system right IT1204 – Software Engineering Institute of Technology, University of Moratuwa 8
- 9. Requirement may solve the dual function IT1204 – Software Engineering Institute of Technology, University of Moratuwa 9 May be the basis for a bid for a contract •Therefore must be open to interpretation May be the basis for the contract itself •Therefore must be defined in detail
- 10. Requirements • “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. • The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. • Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. • Both of these documents may be called the requirements document for the system
- 11. Type of Requirements 1. Business Requirements • Why the organization is undertaking the project • They state some benefits that the developing organization or its customers expect to receive from the product • Several documents such as a project charter, business case, or in a project vision and scope statements • Problem Statement • Project Vision • Project Constraints (Budget, Schedule, and Resources) • Project Objectives • Project Scope Statements • Business Process Analysis • Stakeholder Analysis IT1204 – Software Engineering Institute of Technology, University of Moratuwa 11
- 12. Type of Requirements 2. User Requirements • Describe what the user does with the system • An important and difficult step of designing a software product is determining what the user actually wants it to do • The information they provide may also be incomplete, inaccurate and self- conflicting IT1204 – Software Engineering Institute of Technology, University of Moratuwa 12
- 13. Type of Requirements 3. System/Software Requirements • The traditional “shall” statements that describe what the system “shall do.” • The building blocks developers use to build the system • Incorporate both software and hardware components • It may also include training and organizational change requirements • Domain, Functional and Non-Functional requirements IT1204 – Software Engineering Institute of Technology, University of Moratuwa 13
- 14. Types of System/Software Requirements IT1204 – Software Engineering Institute of Technology, University of Moratuwa 14
- 15. Type of System/Software Requirements Functional Requirements • End user specifically demands as basic facilities that the system should offer • Need to be necessarily incorporated into the system as a part of the contract • Input to be given to the system, the operation performed and the output expected Non-Functional Requirements • Quality constraints that the system must satisfy according to the project contract • Requires the knowledge of the functionality of the system, as well as the knowledge of the context within which the system will operate Domain Requirements • Characteristic of a particular category or domain of projects
- 16. Requirement Engineering Process of establishing the needs of stakeholders that are to be solved by a software IT1204 – Software Engineering Institute of Technology, University of Moratuwa 16
- 17. Problems with natural language IT1204 – Software Engineering Institute of Technology, University of Moratuwa 17 Precision is difficult without making the document difficult to readLack of clarity Functional and non-functional requirements tend to be mixed-up Requirements confusion Several different requirements may be expressed together Requirements amalgamation The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult Ambiguity The same thing may be said in a number of different ways in the specification Over-flexibility
- 18. The Requirements Engineering Process IT1204 – Software Engineering Institute of Technology, University of Moratuwa 18
- 19. Requirements specification Requirements validation Requirements elicitation Systemrequirements specification and modeling System requirements elicitation User requirements specification User requirements elicitation Business requirements specification Prototyping Feasibility study Review s System requirements document IT1204 – Software Engineering Institute of Technology, University of Moratuwa 19
- 20. Feasibility Study • Aims to answer three basic questions: • Would the system contribute to overall organizational objectives? • Could the system be engineered using current technology and within budget? • Could the system be integrated with other systems already in use?
- 21. Feasibility study issues (a high-level checklist) IT1204 – Software Engineering Institute of Technology, University of Moratuwa 21 How would the organization cope if the system wasn’t implemented? What are the current process problems and how would the system help with these? What will the integration problems be? Is new technology needed? New skills? What must be supported by the system, and what need not be supported?
- 22. Requirements Elicitation IT1204 – Software Engineering Institute of Technology, University of Moratuwa It is the practice of obtaining the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as Requirement gathering. 22
- 23. Requirements Elicitation • Guidelines of Requirements Elicitation • Assess the business and technical feasibility for the proposed system • Identify the people who will help specify requirements. • Define the technical environment (e.g. computing architecture, operating system, telecommunication needs) into which the system or product will be placed • Identify “domain constraints” (i.e. characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to build • Define one or more requirements elicitation methods (e.g. interviews, team meetings, ..etc) • Solicit participation from many people so that requirements are defined from different point of views. • Create usage scenarios of use cases to help customers/ users better identify key requirements. IT1204 – Software Engineering Institute of Technology, University of Moratuwa 23
- 24. Requirements Analysis IT1204 – Software Engineering Institute of Technology, University of Moratuwa Requirements Analysis, determining whether the stated requirements are clear, complete, consistent and unambiguous. 24
- 25. Requirements Analysis Stakeholder Identification • Stakeholders are people or organizations that have a valid interest in the system. They may be affected by it directly or indirectly. • Stake holders may include: • Anyone who operates the system • Anyone who benefits from the system • Anyone involved in purchasing or procuring the system • People opposed to the system (negative stakeholders) • Organizations responsible for the system IT1204 – Software Engineering Institute of Technology, University of Moratuwa 25
- 26. Requirements Analysis Stakeholder Interviews • Interviews are a common technique used in requirement analysis. • This technique can serve as a means of obtaining the highly focused knowledge from different stakeholders perspectives IT1204 – Software Engineering Institute of Technology, University of Moratuwa 26
- 27. Requirements Specifications Requirements Specification is the direct result of a requirement analysis and can refer to: • Software Requirements Specification • Hardware Requirements Specification IT1204 – Software Engineering Institute of Technology, University of Moratuwa 27
- 28. Requirements Validation and Verification • Validation (& Verification), is the process of checking whether the requirements, as identified, do not contradict the expectations about the system of various stakeholders and do not contradict each other • Quality control of the requirements IT1204 – Software Engineering Institute of Technology, University of Moratuwa 28
- 29. Validation Vs. Verification Validation: “Am I building the right product?” checking a work product against higher-level work products or authorities that frame this particular product. • Requirements are validated by stakeholders Verification: “Am I building the product right?” checking a work product against some standards and conditions imposed on this type of product and the process of its development. • Requirements are verified by the analysts mainly IT1204 – Software Engineering Institute of Technology, University of Moratuwa 29
- 30. Thank you IT1204 – Software Engineering Institute of Technology, University of Moratuwa 30
Editor's Notes
- #3: Requirements engineering help software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants and how end-users will interact with the software.
- #8: RE bridge the Gap
- #16: Functional Requirements - For example, in a hospital management system, a doctor should be able to retrieve the information of his patients. Each high-level functional requirement may involve several interactions or dialogues between the system and the outside world. In order to accurately describe the functional requirements, all scenarios must be enumerated. There are many ways of expressing functional requirements e.g., natural language, a structured or formatted language with no rigorous syntax and formal specification language with proper syntax. Defines functions of a software system or its components. They may be calculations, technical details, data manipulation and processing and other specific functionality that define “what a system is supposed to accomplish?” They describe particular results of a system. Functional requirements are supported by Non-functional requirements. Non- Functional Requirements – They are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behavior. Functional requirements define what the system is supposed to do, whereas non-functional requirements define how a system is supposed to be. Non-functional requirements can be divided into two main categories: Execution qualities, such as security and usability, which are observable at runtime. Evolution qualities, such as testability, maintainability and scalability. Portability Security Maintainability Reliability Scalability Performance Reusability Flexibility Domain Requirements - For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement. These requirements are therefore identified from that domain model and are not user specific.
- #20: Emphasizes iterative nature of core activities
- #21: An engineered system is a system designed or adapted to interact with an anticipated operational environment to achieve one or more intended purposes while complying with applicable constraints
- #31: The 5 Key Principles Of User Experience Design Hierarchy Consistency Confirmation User Control Accessibility