Kiến trúc máy tính và hợp ngữ - Chapter 1: Introduction of software requiremnet

Software Life Cycle Process What is Requirement? Requirement Engineering Types of requirements [1] Ralph R. Young - The Requirements Engineering Handbook- 2004 Artech House, Inc. [2] Karl E. Wiegers, Software requirement, Second Edition- Microsof t Press © 2003(ebook) [3] Brian Berenbach, Daniel J. Paulish, Juergen Kazmeier, Arnold Rudorfer - Software & Systems Requirements Engineering: In Practice- Mc GrawHill, 2009 [4] Ian Alexander, Ljerka Beus-Dukic – Discovering Requirements - John Wiley and Sons, Ltd., Publication Systems development life cycle (SDLC) The series of steps used to mark the phases of development for an information system.  The SDLC has a set of five fundamental phases: Planning Analysis Design Implementation Test A phase = a series of steps, which rely upon techniquesthat produce deliverables 28/4/2014 4 28/4/2014 5 Structured design Waterfall Parallel Development RAD Phased Developmen Prototyping RUP Agile Development extreme programming (XP), Scrum Dynamic Systems Development Method (DSDM). 28/4/2014 6 28/4/2014 7 28/4/2014 8 28/4/2014 9 RUP has 4 phases: Inception (Khởi đầu) Elaboration (Triển khai) Construction (Xây dựng) Transition (Chuyển giao) Each phase ends at a major milestone and contains one or more iterations Inception Elaboration Construction Transition time Requirement is something wanted or needed. Hence, requirements on particular system/application are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.  Distribution of Defects  Distribution of Effort to Fix Defects Code 7% Other 10% Design 27% Requirements 56% Code 1% Other 4% Design 13% Requirements 82% Source: Martin & Leffinwell 14 Why combining RE with modeling ? For analysis – models help to understand the problem domain For documentation – models can be used for describing requirements (instead of solely using natural language) 15 Requirements Engineering (RE) is: The activity of development, elicitation, specification, analysis, and management of the stakeholder requirements, which are to be met by a new or evolving system. RE is concerned with identifying the purpose of a software system and the contexts in which it will be used How/where the system will be used Big picture is important 16 Requirements Engineering (RE): Captures real world needs of stakeholders affected by a software system and expresses them as artifacts that can be implemented by a computing system Bridge to design and construction How to communicate and negotiate? Is anything lost in the translation between different worlds? 17 RE Requirement Development Requirement Management Elicitation Analysis Specification Validation Reqruirement Inception Indentify business need  Build a business case Preliminary feasibility assessment Preliminary definition of project scope Identify the stakeholders Recognize multiple viewpoints Work toward collaboration Break the ice and initiate the communication Requirement Development includes all the activities involved with gathering, evaluating, and documenting the requirements for a software or software-containing product. Eliciting requirements is difficult because of Project scope and purpose in identifying the boundaries of the system or specifying too much technical detail rather than overall system objectives Problems of understanding what is wanted, what the problem domain is, and what the computing environment can handle (Information that is believed to be "obvious" is often omitted) Problems of volatility because the requirements change over time Overview of different techniques Brainstorming Interviews Task observations Use cases / scenarios Prototyping More ... Analyse, refine, scrutinize the gathered requirement Detect and resolve conflicts between requirements  make consistent and unambiguous requirements Discover the bounds of the software and how it must interact with its environment Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous terms. Developing Software Requirement Specification, focus of the project moves from the broad statement of user needs, goals and objectives, target markets and features of the system to the details of how these eatures are going to be implemented in the solution. Requirement must be validated to ensure that The software engineer has understood the requirements  delivery of what the client wants Requirements document conforms to organizational standards Different stakeholders, including representatives of the customer and developer, shall review the document  Validation: checks that the right product is being built  Verification: checks that the product is being built right During design phase: refers back to the specification of the system or software requirements During RE: mainly checking consistency between different requirements, detecting conflicts Techniques used during RE Simple checks Formal Review Logical analysis Prototypes and enactments Design of functional tests Development of user manual Requirement Management is to organize and manage of Requirements to ensure all requirements are satisfactorily implemented and accepted. Software requirements include four distinct levels: Business requirements User requirements Functional requirements Non-Functional requirements Business requirements User requirements Functional requirements Non-functional requirements Represent high-level objectives of the organization or customer who requests the system Come from the funding sponsor for a project, the acquiring customer, the manager ... Describe why the organization is implementing the system—the objectives the organization hopes to achieve record the business requirements in a vision and scope document, sometimes called a project charter or a market requirements document. Describe user goals or tasks that the users must be able to perform with the system. Valuable ways to represent user requirements include use cases, scenario descriptions, and event-response tables. An example of a use case: "Make a Reservation" using an airline, a rental car, or a hotel Web site Specify the software functionality that the developers must build into the product to enable users to accomplish their tasks Describe what the system should do What inputs the system should accept What outputs the system should produce What data the system should store other systems might use What computations the system should perform The timing and synchronization of the above 35 Example: The user shall be able to search either all of the initial set of databases or select a subset from it. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area. A requirement that is not functional. Include many different kinds of requirements: Performance requirements Design constraints (also called process requirements) Commercial constaints Performance requirements characterize system properties such as expected performance, capacity, reliability, robustness, usability, etc. reflecting: usability, efficiency, reliability, maintainability and reusability Design constraints (also called process requirements)  providing constraints on how the system should be designed and built – related to development process, documentation, programming language, maintainability, etc. Categories constraining the environment and technology of the system. Platform (minimal requirements, OS, devices) Technology to be used (language, DB, ) Commercial constaints: Categories constraining the project plan and development methods Development process (methodology) to be used Cost and delivery date Often put in contract or project plan instead Example: Any interaction between the user and the system should not exceed 2 seconds Only direct managers can see personnel records of staff Complete Correct Feasible Necessary Prioritized Unambiguous Verifiable Requirement Specification is a description of how a system should behave or a description of system properties or attributes. It can alternatively be a statement of “what” an application is expected to do.