Requirements engineering IDY0201

Transcription

1 Requirements engineering IDY0201 Enn Õunapuu cloud.ld.ttu.ee/idy0201/

2 Definition

3 Definition Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. Requirement engineering is a subdiscipline of systems engineering and software engineering

4 Definition SWEBOK At its most basic, a software requirement is a property which must be exhibited in order to solve some problem in the real world. Hence, a software requirement is a property which must be exhibited by software developed or adapted to solve a particular problem. The problem may be to automate part of a task of someone who will use the software, to support the business processes of the organization.

5 Requirements analysis Conceptually, requirements analysis includes three types of activity: Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

6 Types of Requirements Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis. Performance Requirements The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. Design Requirements The build to, code to, and buy to requirements for products and how to execute requirements for processes expressed in technical data packages and technical manuals. Derived Requirements Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight. Allocated Requirements A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

7 SWEBOK Developed concurrently, the SWEBOK Guide, the Software Engineering 2004 (SE2004) curriculum guide, and the Certified Software Development Professional (CSDP) certification each provided a characterization of the discipline of software engineering. Despite nearly independent development, the three instruments agreed to a remarkable extent. The primary purpose of the current revision of the SWEBOK Guide is to perfect the correspondence between the three items, notably by adding a KA on professional practices a subject currently covered by the CSDP and adding foundation KAs on related subjects that software engineers learn about during their undergraduate education subjects currently covered by SE2004.

8 Defining a good requirement Correct (technically and legally possible). Complete (express a whole idea or statement). Clear (unambiguous and not confusing). Consistent (not in conflict with other requirements). Verifiable (it can be determined that the system meets the requirement). Traceable (uniquely identified and tracked). Feasible (can be accomplished within cost and schedule). Modular (can be changed without excessive impact). Design-independent (do not pose specific solutions on design)

9

10

11 Standardid EVS-ISO/IEC :2003 Software engineering Product quality Part 1: Quality model

12

13

14

15

16

17 The State in the Cloud Application State Separated from the Machine Per-User Per-App State Safety and Sand- Boxing Controlled and Safe Sharing across Apps Controlled and Safe Sharing across Users

18 Enterprise service bus

19 A Value-Based Software Process Framework Barry Boehm and Apurva Jain

20 SYSML

21 MDA

22 Questions??