Software Engineering Week 2 Requirements (1) PDF

CP317 Software Engineering week 2-2 Requirement gathering – part -2 Shaun Gao, Ph.D., P.Eng. Agenda Review week 2-1 Gathering requirements Requirement elicitation Techniques Task analysis Domain analysis Brainstorm Alex F. Osborn four r...

CP317 Software Engineering week 2-2 Requirement gathering – part -2 Shaun Gao, Ph.D., P.Eng. Agenda Review week 2-1 Gathering requirements Requirement elicitation Techniques Task analysis Domain analysis Brainstorm Alex F. Osborn four rules about brainstorm Requirement specification Recording requirements Documentation Unified modeling language (UML) Requirements validation and verification Summary Review week 2-1 Requirements The reasons why requirements are important The characteristics of good requirements Understandable, correct, unambiguous, complete, consistent, interoperable, verifiable, traceable, prioritized, achievable Requirement prioritization MOSCOW method Requirement categorization Business/ user/ system Business requirements, user requirements, system requirements FURPS and FURPS+ methods Functional requirements, Non-functional requirements Differences between functional requirements and non-functional requirements Difference between requirement prioritization and categorization? 2020 Findings Failure causes of IT projects Cite from Capella University Gathering requirements Requirements elicitation process Discovery Classification and organization Prioritization and negotiation Specification Gathering requirements – cont. Think – Pair - Share Question? Requirements are there, why do we need requirement discovery? Requirements elicitation process Requirement discovery Requirement discovery is the process of working with customers to understand their needs, blueprint the solution, gather detailed requirements, design technical aspects. Classification and organization/Categorization FURPS/FURPS+ Prioritization and negotiation MoSCOW Specification Requirements specification is a document that clearly and precisely describes each of the essential requirements (functions, interfaces, design constraint, and quality attribute) of the software and external interfaces. Requirements elicitation techniques NO. Techniques Details 1 Communications It includes interview, surveys and questionnaires 2 Task analysis Team of engineers and developers may analyze the operation for which the new system is required. 3 Domain analysis It is the process by which a software engineer learns background information. Embedded, middleware, etc. 4 Brainstorming A discussion meeting is held among various stakeholders. Requirements elicitation techniques – cont. NO. Techniques Details 5 Prototyping It is building a prototype product (for example, user interface) without adding detail functionality to interpret the features of intended software product. 6 Observation Team of experts visit the client’s organizations or workplace. They observe the actual working of the existing systems. Requirements elicitation techniques – cont. Task analysis PERT chart Task analysis is the process of learning how a task is accomplished, including a detailed description of activities of the task, conditions, necessary equipment, and any other factors. "task" is often used interchangeably with activity or process. Requirements elicitation techniques – cont. Task analysis questions Requirements elicitation techniques – cont. Domain analysis It is a process by which a software engineer learns back ground information. “Domain” means the general field of business or technology in which the customers expect to use the software product. For example, airline reservation systems, medical diagnosis systems, etc. Purpose: Gain sufficient information, understand the system/problems, and make good decisions Benefits of domain analysis: Shorten the duration of the project Increase the quality of software products Anticipation of extensions Requirements elicitation techniques – cont. Brainstorm: NO. Four rules of Osborn’s Meanings Brainstorm is a group creativity method technique by which efforts are 1 Focus on quantity Do everything you can to made to find a conclusion for a keep the idea flowing specific problem by gathering a list of ideas spontaneously 2 Withhold criticism Criticism can make people stop contributing contributed by its members. Four rules of Osborn’s method 3 Encourage unusual You can always “turn down a in Brainstorm ideas wild idea” but you may need to think way outside of the Alex F. Osborn developed box to find creative solutions. methods for creative problem solving in 1939. 4 Combine and improve Form new ideas by ideas combining other ideas. Requirement specification You make design decisions or ask for requirement changes Use scientific principles to design and build high quality software products Requirement specification – cont. Software requirement decomposition Definition: software requirement decomposition is to break down a software system from the system context level to system functions and data entities levels. An example: Recording requirements Unified modeling language (UML): https://www.uml.org/ UML is a general-purpose notational language for specifying and visualizing complex software, especially large, object-oriented project. UML is not a programming language; it is rather a visual language. Engineers use UML diagrams to portray the behavior and structure of a system. UML is applicable for any types of software design Database design Recording requirements – cont. Unified modeling language (UML) more in later lectures Validation and verification Requirement validation Requirement validation is the process of making sure that the requirements say the right things. Requirement verification Requirement verification is the process of checking that the software product actually satisfies the requirements. Validation and verification Verification vs. validation in software engineering Summary Gathering requirements Requirement elicitation Six techniques: communication, task analysis, domain analysis, brainstorm, prototype, observation Alex F. Osborn four rules about brainstorm Requirement specification Recording requirements Documentation Unified modeling language (UML) Requirements validation and verification Verification vs. validation Please apply what you learned to the group project. Announcement It is your responsibility to find a group by the end of January. If you cannot find one, I am willing to help.