Introduction to Requirement Engineering: A Comprehensive Guide, Schemes and Mind Maps of Software Engineering

Download Introduction to Requirement Engineering: A Comprehensive Guide and more Schemes and Mind Maps Software Engineering in PDF only on Docsity!

Chapter 1

Introduction to Requirement Engineering Tadele M.

2  What are requirements?  Types of requirements  Functional, non-functional & domain requirements  Business, user & System requirements  Requirement Engineering: Introduction  What is requirement engineering?  Why Requirement Engineering?  Requirement requirements: How  Requirement requirements: When  Stakeholders in Requirement Engineering: Who

Contents

 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 document  a documented representation of a condition or capability as in definition 1 or 2 [IEEE 1990 a].

 Requirement: A statement that identifies a product

or process operational, functional, or design

characteristic or constraint, which is un ambiguous,

testable or measurable, and necessary for product

or process acceptability (by consumers or internal

quality assurance guidelines).

4

5 Requirements might describe:

• A user-level facility (e.g. the word processor must include a spell checking and correction command)
• A very general system property (e.g. the system must ensure that personal information is never made available without authorization)
• How to carry out some computation (e.g. the overall mark is computed by adding the students exams, project & individual assignment marks based on the following formula. Total = [mid exam + final exam + project + individual assignment])
• constraint on the development of the system (e.g.
  • The system must be developed using java,
  • The system will only use the data contained in the existing corporate database.) Etc..

 The most common reasons for project failures are not technical. Below the main reasons why projects fail is identified. The data is drawn from surveys conducted by the Standish Group in 1995 and 1996.  Incomplete requirements 13.1%  Lack of user involvement 12.4%  Lack of resources 10.6%  Unrealistic expectations 9.9%  Lack of executive support 9.3%  Changing requirements/specifications 8.7%  Lack of planning 8.1%  Didn’t need it any longer 7.5% Hence giving emphasis to requirements is crucial in any system dev’t. 7

8  Software requirements are often classified as functional requirements, non-functional requirements or domain requirements.  Functional requirements: Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. i.e. “What the system should do?”.  IEEE defines functional requirements as 'a function that a system or component must be able to perform.'  Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

Types of requirements

10  NR place restrictions on the product being developed, the development process , and specify external constraints that the product must meet.  Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.  Example  The product must be available at the beginning of the next year.  The application must support android devices running on OS version 9.  The system shall be easy to use.  The system should not fail more than twice in a week.  The system shall respond to every user action in less than 3 sec.

Types of requirements…

11  Functional Vs Non-Functional Requirements  There is no a clear distinction between functional and non- functional requirements.  Whether or not a requirement is expressed as a functional or a non-functional requirement may depend on:  the level of detail to be included in the requirements document.  the degree of trust which exists between a system customer and a system developer. Types of requirements…

13  Domain Requirements  Domain requirements are expectations related to a particular type of software, purpose or industry vertical like military, medical and financial industry sectors  Requirements that come from the application domain of the system and that reflect characteristics of that domain.  They are the requirements which are characteristic of a particular category or domain of projects.  Domain requirements are not from specific needs of system users and can be functional or non-functional.  They usually include specialized terminologies reference to domain concept - they are difficult to understand  They may be new functional requirements (may be defining specific computations) or can be constraints on existing requirements.  If domain requirements are not satisfied, the system may be unworkable.

Types of requirements…

 For example,  The system safety shall be assured according to standard IEC 60601 - 1:Medical Electrical Equipment – Part 1:General Requirements for Basic Safety and Essential Performance.  Domain requirements problems  Understandability  Req’ts are expressed in the language of the application domain; often not understood by software engineers.  Implicitness  Domain specialists understand the area so well that they do not think of making the domain requirements explicit. 14

16

 User Requirements:

 User requirements add further detail to the business requirements.  What services the system is expected to provide to system users and the constraints under which it must operate.  They are called user requirements because they are written from a user’s perspective and the focus of user requirement describe tasks the user must be able to accomplish in order to fulfill the above stated business requirements.

 E.g. The system should be easy to use by site

engineers and should be organized in such a way that user errors are minimized.

17 System Requirements:  Detailed description of what the system should do including the software system's functions, services, and operational constraints.  The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented.  are expanded versions of the user requirements that are used by software engineers as the starting point for the system design.  They add detail and explain how the user requirements should be provided by the system  Written as a contract between client and contractor

19 Requirement Engineering: Introduction  Requirement Engineering is the process of defining, documenting and maintaining the requirements.  It is the process of understanding and defining what services are required and identifying the constraints on these services.  Requirement engineering provides  the appropriate mechanism to understand what the customer desires,  analyzing the need, and assessing feasibility,  negotiating a reasonable solution,  specifying the solution clearly,  validating the specifications and  managing the requirements as they are transformed into a working system.

20  Requirements Engineering(RE) provides the basic agreement between end-users and developers on what the software should do.  RE “involves all life-cycle activities devoted to identification of user requirements, analysis of the requirements to derive additional requirements, documentation of the requirements as a specification, and validation of the documented requirements against user needs, as well as processes that support these activities” (DoD 1991 ).  A branch of SWE concerned with the real world goals for, functions of, and constraints on software systems and also concerned with the relationship of these factors to precise specifications of software behavior (Zave 1997 ).