CSEB233: Fundamentals of Software Engineering. Software Requirements Part 1 Understanding Requirements Engineering

Transcription

1 CSEB233: Fundamentals of Software Engineering Software Requirements Part 1 Understanding Requirements Engineering

2 Objectives Discuss the concept of requirements and the types of requirements Explain what Requirements Engineering is, its process, and its importance to product development projects Explain and relate requirements elicitation, requirements analysis and negotiation, requirements specification, requirements verification and validation, and requirements management activities Describe various methods, approaches, and techniques for performing and supporting the Requirements Engineering process

3 Understanding Requirements Engineering Concept and Types of Requirements

4 What are Requirements? IEEE Standard Glossary of Software Engineering Terminology (IEEE, 1990): A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that shall be met or possessed by a system, system component, product or service to satisfy a contract, an agreement, standard, specification or other formally imposed documents A documented representation of a condition or capability as in (1) and (2).

5 Types of Requirements Three types of requirement Functional Requirements (FR) Non-functional Requirements (NFR) also known as Quality Requirements Constraints

6 Functional Requirements IEEE Standard Glossary of Software Engineering Terminology (1990) define FR as: a requirement that specifies a function that a system or system component must be able to perform Function is defined as: a defined objective or characteristic action of a system or component For example, a system may have inventory control as its primary function

7 Functional Requirements Functional requirements relate to the actions (such as calculate, retrieve, display) that the system or system component must carry out in order to satisfy the reason for its existence (Robertson & Robertson, 1999)

8 Functional Requirements Describe the services a system or component of a system should perform Tell you and your users how the system should react to certain inputs Describe how the system should and/or should not behave in particular situations Must not include quality statement such as 'fast', efficient, usable, reliable, and etc. Are important for the developers to use them to develop the system as expected by the customers

9 Non-functional Requirements A requirement that specifies quality property of the entire system, a system component, service or function. Quality property is usually associated with the system as a whole and not to individual function. It will affect degree of user satisfaction. Product - specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organizational - a consequence of organizational policies and procedures, e.g. process standards used, implementation requirements, etc. External - arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

10 Non-functional Requirements Examples

11 Non-functional Requirements Examples

12 Non-functional Requirements Examples

13 Non-functional Requirements Examples

14 Constraints A constraint is an organizational or technological requirement that restricts the way in which the system shall be developed. Constraints are non-negotiable and are off-limits during design trade-offs.

15 Constraints Example constraints: Cultural constraints User interfaces shall not contain abusive symbols or graphics for any culture Legal constraints Creation of invoices shall consider the goods and services tax of 6% Physical constraints Engine control units in the vehicle interior shall work at temperatures from -10 to +50 degree celcius Project constraints The overall development effort must not exceed RM 1,000,000.

16 Exercises Which of the following are FR, NFR and constraints? The house information system shall generate monthly statements of allowed and denied accesses. The release of the locking mechanism shall take 0.8 seconds at most. If a sensor detects a damage of the window, the system shall inform the security company. If a correct PIN is entered at the keyboard of the access system, the system shall remove the door lock and shall record access date, time and the PIN entered. The effort for system development shall not exceed 480 person months. The user password stored in the system shall be protected against unauthorized access. The system shall be developed using Rational Unified Process

17 Understanding Requirements Engineering What is Requirements Engineering?

18 What is Requirements Engineering (RE)? a relatively new term which has been invented to cover all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. The use of the term engineering implies that systematic and repeatable techniques should be used to ensure that systems are complete, consistent, relevant, etc. Sommerville & Sawyer (1997) the process of developing a requirements specification Pohl (1996) the broad spectrum of tasks and techniques that lead to an understanding of requirements Pressman (2009)

19 Why is RE important? RE process can influence the development cost, time, effort, and quality of the product RE process is an essential contributor to the overall quality of the software product Incomplete requirements, changing requirements are major causes of project failures Good RE practices contribute more than 42% towards the overall success of a project, while improper RE practices account for more than 43% of the reasons why projects are late or over budget (CHAOS, 1995)

20 How Far Have We Got?

21 How Far Have We Got?

22 ( Importance of RE How the customer explain it How the project leader understood it How the analyst design it How the programmer wrote it How the business consultant described it How the project was documented What operations installed How the customer was billed How it was supported What the customer really needed

23 RE Framework

24 Framework Motivation Structuring requirements engineering by defining a set of core common concepts for each requirements engineering process and their relationships Reference structure for industry Training of managers, requirements engineers and developers. Analysis of strength and weaknesses of RE processes. Reference structure for teaching requirements engineering Successfully introduced in a number of organizations, companies and universities!

25 Context The requirements engineering context consists of 1. The system context is the part of the context in which the system to be developed is operating/embedded. Subject facet comprises system context objects about which information is represented in the system or which influence or constrain the representation of information represented in the system. Usage facet comprises all system context objects (people and/or systems) which directly or indirectly interact with the system or which influence or benefit from the usage of the system. IT system facet comprises all system context objects of the technical and operational environment in which the system is going to be deployed in or which influence or constraint the deployment of the system and/or the use of technology by the system such as sensors, actuators or other systems. 2. The development context is the part of the context in which the system is being developed.

26 Core Activities Elicitation Negotiation Documentation

27 Elicitation The goal of the elicitation activity is to: 1. Identify relevant requirements sources 2. Elicit existing requirements from the identified sources 3. Develop new and innovative requirement Requirements sources are not always known at the beginning of the process! Relevant requirements sources include: Stakeholders involved in the process, existing documents existing systems

28 Negotiation The goal of the negotiation activity is to: 1. Identify conflicts 2. Analyse the cause of each conflict. 3. Resolve the conflicts by means of appropriate strategies. 4. Document conflict resolution and their rationale. Wishes and needs of the stakeholders typically vary and can be in conflict Conflicts shall be identified and should be resolved

29 Documentation The goal of the documentation activity is to: 1. Document relevant requirements information according to the defined documentation guidelines. 2. Specify requirements according to the defined specification guidelines. 3. Choose documentation formats and notations which fit the stakeholder needs, and are defined for the project. 4. Ensure consistency between different documentation formats used. In addition to the requirements, information about elicitation and negotiation should be documented. Early in requirements engineering, information is often documented informally/unstructured and thus not compliant with the documentation and specification rules.

30 Artefacts A goal describes a high level objective of one or more stakeholders about a property of the system to be developed or the development project A scenario describes a concrete example of satisfying or failing to satisfy a goal (or set of goals). Three Types of Solution-oriented Requirements Data perspective considers the static data structures. It defines data types, attributes and relationships between data types. Functional perspective considers the manipulation of data by system functions. It defines the transformation of inputs by functions into outputs. Behavioural perspective considers the system behaviour. It defines the reactions to external stimuli in form of permitted states, transitions and outputs.

31 Three types of Solution-oriented Requirements

32 Cross-sectional activities Validation Management

33 Validation Three Validation Goals Validation of requirement artifacts Aims at detecting defects in requirements. Validating the artefacts with regard to the content, the documentation and the agreement dimensions. Checking the fulfilment of validation criteria. Validation of the core activities Checking the compliance of the activities performed and the process and/or activity specifications. Have all required steps been performed? Have the required stakeholders been involved in the activities? Validation of the context consideration Checking whether the context has been considered adequately in the activities. Have all relevant requirements sources been considered? Have the required stakeholders been involved? Have all parts of the requirements engineering context been sufficiently considered?

34 Management Three Management Goals Management of the requirements artifacts throughout the system lifecycle: Prioritization of requirements. Persistent recording. Configuration management. Change management. Requirements traceability. Management of the core activities Ensure an efficient and effective overall RE process. Plan and control the execution of the RE activities. Alignment of the process to the current project situation. Management of the context Identifying changes in the context relevant for the system. Changes typically require (re-)initiating or (re-)scheduling of one or more RE activities.

35 Understanding Requirements Engineering Requirements Elicitation

36 Goal As mentioned earlier, the goal of the elicitation activity is threefold. 1. To identify relevant requirements sources 2. To elicit existing requirements from the identified sources 3. To develop new and innovative requirement Three types of requirements sources Documents Existing systems Stakeholders

37 Sources Documents Existing documents contain relevant information to be considered when defining the requirements for the desired system. Documents can be general (e.g. standards), organization specific (e.g. development guidelines) or product-specific (e.g. code, user manual). Stakeholders Either a person or an organization with potential interest in the desired system. A person can represent the interest of different stakeholders. Existing systems Requirements realized by the existing system might still be relevant for the new system. Existing systems can be used to identify enhancements, known deficiencies and previous errors.

38 Elicitation Components Four components of requirements elicitation: Understanding application domain this is about knowledge of the general area where the system is applied. Understanding problem to be solved understand details of the problem where the software will be applied. Understanding business processes in an organization understand how systems interact and affect the different part of the business and how they contribute to overall business goals. Understanding the needs and constraints of the stakeholders understand the work processes that the system is intended to support, the ways in which the system is likely to be used, and restrictions on the degree of freedom we have in providing a solution.

39 Main Elicitation Techniques Interview Elicitation of requirements and context information from a stakeholder or a group of stakeholders Workshop A group of stakeholders develops requirements for a system Focus Group A group of stakeholders focus on a specific item to identify the requirements regarding this item Observation An observer elicits requirements by observing stakeholders of existing systems Questionnaire A stakeholder writes down his requirements by answering predefined questions Perspective-based Reading A stakeholder reads a document from a previously defined perspective, e.g. from the perspective of a user or from the perspective of a tester

40 Other Supporting Techniques Brainstorming Prototyping KJ method Mind mapping Elicitation checklists

41 Elicitation Work Products A statement of need and feasibility A bounded statement of scope for the system or product A list of customers, users, and other stakeholders who participated in requirements elicitation A description of the system s technical environment A list of requirements (preferably organized by function) and the domain constraints that apply to each A set of usage scenarios that provide insight into the use of the system or product under different operating conditions Any prototypes developed to better define requirements

42 Why is it difficult to understand what the customer wants? Problems of scope System/software boundary is ill-defined Customers/users specify unnecessary technical detail that may confuse overall system/software objectives Problems of volatility Requirements change over time (Christel and Kang, 1992)

43 Why is it difficult to understand what the customer wants? Problems of Understanding Customers/users not sure what they want Poor understanding of the capabilities and limitations of their own computing environment Don t have full understanding of the domain problems Have trouble communicating need Omit information that is believed to be obvious Specify ambiguous requirements I want a user friendly interface in the XYZ system. Specify conflicting requirements

44 Understanding Requirements Engineering Requirements Negotiation

45 Goal A process of discussing the conflicts in the requirements and finding resolutions to the identified conflicts The goal of the negotiation activity is to: 1. Identify conflicts 2. Analyse the cause of each conflict. 3. Resolve the conflicts by means of appropriate strategies. 4. Document conflict resolution and their rationale.

46 Conflict A conflict in requirements engineering exists, if the needs and wishes of different stakeholders regarding the system contradict each other, or if needs and wishes cannot be considered. Unresolved conflicts have negative impact on the acceptance of the system by the stakeholder. When resolving conflicts, often new ideas and innovative requirements are developed thus conflicts should be positively seen as opportunities!

47 Conflict Examples A group of stakeholders demands the use of radar sensors for distance measurement. Another group of stakeholders asks, instead, for ultrasound sensors. A stakeholder demands to display safety-relevant information for the driver on a head-up display. Other stakeholders argue this would detract the driver and hence reject this requirement.

48 Conflicts In any set of requirements, there will always be conflicts, overlaps, and omissions Developer must anticipate these and plan requirements negotiation with all stakeholders to discuss and resolve the problems Requirements conflicts are inevitable because different stakeholders have different requirements and priorities One technique to identify conflicts and overlaps is by using Interaction Matrix

49 Types of Conflict Data conflict Wrong, incomplete information about requirements, different interpretation, different views and different assessment Interest conflict Interests or goals with regard to the system contradict each other Value conflict Different ways of life, ideology or religion resulting in each stakeholder considering the importance of a requirement differently. Relationship conflict Strong emotions, deficient communication and negative interpersonal behavior between stakeholders Structural conflict Unequal balance of authority or power, destructive patterns of interaction, unequal control, ownership or distribution of resources and time constraints

50 Conflicts Resolution Three basic strategies for resolving data, value and interest conflicts. Negotiation The conflict parties agree on a solution by means of negotiation Creative solution The original viewpoints of the conflicting parties are discarded and a new, creative unanimous solution is developed. Decision A higher authority makes a decision in favour of one conflicting party.

51 Prioritizing Requirements To decide which requirements have to be implemented and deliver first, which ones could be implemented in the subsequent deliveries, and which ones could be dropped. Must collaborate with the customers. Why? You may not know which requirements are most important to customers, and Customers may not be able to judge the cost and technical difficulty associated with specific requirements.

52 Techniques of Requirements Prioritization Prioritization scale - A common approach to prioritization is to group requirements into several priority categories. E.g.: MoSCoW method (Coley Consulting, 2008) M - MUST have this. S - SHOULD have this if at all possible. C - COULD have this if it does not affect anything else. W - WON'T have this time but WOULD like in the future Quality Function Deployment Semi-quantitative Analytical Approach - the requirements priority can be calculated once you have estimated the benefit, penalty, cost and risk for the negotiable requirements

53 Understanding Requirements Engineering Requirements Documentation

54 Why Documentation? Persistence to preserve information that otherwise might be forgotten Common reference Promotes communication by having common reference to refer to Promotes objectivity to preserve information from unwanted alteration Support training of new employees Preserve expert knowledge Support problem reflection by filling up gaps and inconsitencies

55 What to be Documented?

56 What to be Documented?

57 How to Document? Textual Natural language text Structured text Templates Model-based Data perspective Behaviour perspective Functional perspective Combined Models with annotations Text with models

58 Textual (using template)

59 Model-based

60 Combined

61 Requirements Specification Also known as Software Requirements Specification (SRS) A specific kind of requirements document which supports later development activities and/or used as contracts. It is an official document that consists of information that should guide the system developers such as designers, programmers, and engineers through the development work of the product

62 Requirements Specification Should involve technical writers appropriate skills for gathering requirements, reviewing historic reports, writing formal documents and reports, and etc. can better assess and plan documentation tasks know how to determine the questions that are of concern to the customers and users regarding nonfunctional requirements like ease of use and usability

63 Software Requirements Specification (SRS) Attributes of a well-written SRS (IEEE Standard ): Correct Unambiguous Complete Consistent Ranked for importance or stability Verifiable Testable Traceable SRS template:

64 Understanding Requirements Engineering Cross Sectional: Requirements Validation

65 Requirements Validation Validation denotes checking whether inputs (context artefacts and consideration), execution and outputs (requirements artefacts and additional information) of the RE core activities fulfill defined quality criteria. Validation is performed by involving relevant stakeholders, other requirement sources as well as external reviewers if necessary.

66 Validation Goals

67 Validation versus Verification

68 Validation Techniques Reviews the requirements specification Desk-check Walkthrough Inspection Checklist Prototyping Acceptance Tests

69 Understanding Requirements Engineering Cross Sectional: Requirements Management

70 Requirements Management Ripple Effect one thing causes a series of other things to happen (e.g., Tsunami) Changes in requirements specified in a requirements document are inevitable and must be allowed However, even seemingly a minor change may unexpectedly require lot of work Main activities in managing requirements artefacts: Managing changes to requirements Managing configuration of requirements and requirements document version control Maintaining requirements traceability Tracking requirements status

71 Ripple Effect

72 Why Requirements Change? Internal Factors 1. Failure to elicit the real requirements of the stakeholders 2. Iterating from requirements to design creates new requirements 3. The implementation team might encounter technical, schedule and/or cost problems in implementing a requirement 4. RE process is iterative and must create a practical process to help manage changing requirements. Failure to create a practical requirements change management process will only cause rework and stress External Factors 1. The problem we are trying to solve somehow change as a result of a changing economy, government regulations, consumer preferences etc. 2. Customers and users understand better what they really require from a system or simply change their minds 3. The customers organization may change its structure, procedures and processes 4. The external environment change, which create new constraints and opportunities

73 Managing Requirements Changes Formal change management is crucial to ensure that the requirements changes maintain the proposed system s support to the fundamental business goals To ensure a consistent approach to change management, organizations should define a set of change management policies and procedures

74 Managing Requirements Changes Basic policies: The change management process includes change management principles and guidelines, and activities of the change management process. The change impact analysis needed to avoid changes from causing overruns in project schedule and budget, or resulting negative impact on the product s quality.

75 Requirements Configuration Management Means detail recording and updating that have been applied to the requirements document, and providing version control, release management, and issue tracking. Benefits (Leffingwell and Widrig, 2003): Prevents any unauthorised and potentially destructive changes to the requirements. Preserves the revisions to requirements document. Facilitates the retrieval and/or recreation of requirements document archives. Prevents simultaneous updates of requirements documents. Prevents conflicting and uncoordinated updates to different document at the same time.

76 Managing Requirements Traceability The ability to describe and follow the life of a requirement, in both a forward and backward direction, i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases (Gotel and Finkelstein, 1994) Technique: traceability matrix to show the dependencies between requirements or links between requirements and other system documents

77 Traceability Matrix Use case Functional Requirements Design Element Code Test Case UC-28 catalog.query.sort Class catalog catalog.sort() search.7 UC-29 catalog.query.import Class catalog catalog.import() catalog.validate() search.8 search.8 search.13 search.14

78 Tracking Requirements Status Monitoring implementation status of each requirement to ensure existing requirements are addressed and traceable throughout the development life cycle Tracking requirements status supports overall project status tracking. e.g. proposed, approved, implemented, verified, deleted, rejected If a project manager knows that 55% of the requirements allocated to the next release have been implemented and verified, 28% are implemented but not verified, and 17% are not yet fully implemented, then he or she has good insight into the project status (Wiegers, 1999a)

79 Summary The concept of requirements and types of requirements What Requirements Engineering is, its process, and the importance of them to product development projects in general What requirements elicitation, requirements analysis and negotiation, requirements specification, requirements verification and validation, and requirements management tasks are Various methods, approaches, and techniques for performing and supporting the RE process

80 THE END Copyright 2014 College of Information Technology