DOCSLIB.ORG

2 Requirements Engineering Framework

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
2 Requirements Engineering Framework 2 REQUIREMENTS ENGINEERING FRAMEWORK 2.1 INTRODUCTION Before considering a detailed requirements-engineering methodology in the remaining chapters, this chapter provides an overview of a number of the important aspects of the requirements-engineering body of knowledge [1]. 2.2 NEEDS AND REQUIREMENTS When describing a system, we make the distinction between ‘needs’ and ‘requirements and, as illustrated in Figure 2-1, there are needs and requirements at a number of levels. There are four major views: an enterprise view, in which enterprise leadership set the enterprise strategies and concepts of operations; a business management view, in which business management derive business needs and constraints as well as formalize their requirements; a business operations view, in which stakeholders define their needs and requirements; and a systems view, in which system designers define the system in logical and physical views. Because terms such as system and subsystem (system element) are level-specific, we define an entity “… a single thing to which a need or requirement refers: an enterprise, business unit, project, system, or system element (which could be a product, process, human, or organisation)” [2]. As shown in Figure 2-1, the enterprise, business management, and business operations views are in the problem domain; the system and system element views are in the solution domain. As discussed in Chapter 1, the problem domain is generally considered to be the responsibility of those who have ownership of the problem to be solved, so the descriptions of the system are predominantly in the language of the customer’s business management and business operations, focusing on what the system needs to be able to do, how well it should be done, and why. We saw in Chapter 1 that these descriptions are called logical (or often functional) descriptions. On the other hand, the solution domain is generally considered to be the responsibility of the developer implementing the solution, most commonly a contractor, so the descriptions of the system in that domain are predominantly in engineering and physical terms, focusing on how the problem is to be solved—that is, how the solution will look once it has been implemented. In Chapter 1 we saw that these latter descriptions are called physical descriptions. In many large organisations, there is a soft boundary between the problem domain and the 33 34 Requirements Practice solution domain in that the customer prepares a draft SyRS which is taken to tender, responded to be tenderers, negotiated with the successful tenderer (the preferred contractor) and then revised to be the SyRS that represents the selected solution of that preferred contractor. Concept of Operations Enterprise Enterprise (ConOps) Strategies Business Preliminary Life‐cycle Concepts: Business Needs and Business Operations (OpsCon), Acquisition, Business Business Requirement Requirements Management Deployment, Support, Retirement Needs Requirements Specification Mission Analysis (BRS) Definition Process Problem Domain Stakeholder Life‐cycle Concepts: Stakeholder Stakeholder Needs Stakeholder Requirement Business OpsCon, Acquisition, Deployment, and Requirements Needs Requirements Specification Operations Support, Retirement Requirements Analysis (StRS) Definition Process System Life‐cycle Concepts: System System System System Requirements System OpsCon, Acquisition, Deployment, Requirements Requirement Definition Process Needs Specification Support, Retirement Requirements Analysis (SyRS) Solution Domain Subsystem Subsystem Life‐cycle Concepts: Subsystem Subsystem Subsystem Subsystem OpsCon, Acquisition, Deployment, Requirements Needs Requirement Requirements Support, Retirement Requirements Analysis Specification Definition Process Needs View Requirements View Figure 2-1. Views, domains, processes and artefacts associated with the definition of needs and requirements [3]. In addition to these vertical views of the process, there are two horizontal views shown in Figure 2-1: the Needs View and the Requirements View. While they tend to coexist at each level of consideration, needs and requirements are different: A need is “… the result of a formal transformation of one or more concepts into an agreed-to expectation for an entity to perform some function or possess some quality (within specified constraints)” [4]. Needs are generally capabilities stated as business needs in the language of business management, as stakeholder needs in the language of stakeholders at the business operations levels, or as needs of the system or system element. A requirement statement is “… the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints)” [5]. Requirements are therefore formal statements that are structured and can be validated. There may be more than one requirement that can be defined for any need. Requirements are Chapter 2 Requirements Engineering Framework 35 elaborated from needs through a process of requirements analysis (also called business analysis [6] or mission analysis [7] at the highest level of application). At the highest level, there is an enterprise view in which enterprise leadership sets business vision, strategic goals and objectives in the form of a Concept of Operations (ConOps), which is also called a Strategic Business Plan (SBP). At the next two levels levels, there are the dual views: at the business management level there are Business Needs and Business Requirements; and at the business operations level there are Stakeholder Needs and Stakeholder Requirements. The transformation of needs into requirements occurs at each level. Here we are interested in the three upper-level major processes: Business Needs and Requirements (BNR) Definition Process. Business management start with the guidance contained in the ConOps, from which they define Business Needs, largely in the form of Preliminary Life-cycle Concept Documents (PLCD) which capture the Preliminary Acquisition Concept, Preliminary Operational Concept (OpsCon) [8], Preliminary Deployment Concept, Preliminary Support Concept, and Preliminary Retirement Concept. Business Needs are elaborated and formalized into Business Requirements, which are documented in the Business Requirements Specification (BRS), which is also called the Business Requirement Document [9]. Stakeholder Needs and Requirements (SNR) Definition Process. Using the Preliminary OpsCon and the other PLCD as guidance, requirements engineers lead stakeholders from the business operations level through a structured process to elicit Stakeholder Needs—in the form of a refined OpsCon document and the completion of the other Life-cycle Concept Documents (LCD)—and transform them into the formal set of Stakeholder Requirements, which are documented in the Stakeholder Requirement Specification (StRS). System Requirements Definition Process. The requirements in the StRS are then transformed by requirements engineers into System Requirements, which are contained in the System Requirement Specification (SyRS) [10]. This document is also referred to as the Solution Requirement Specification Document [11], or simply the System Specification [12]. Note that Figure 2-1 illustrates that a number of SyRS may be derived from the StRS—that is, perhaps, one SyRS is produced for each element of a capability. Figure 2-1 also illustrates that some organisations may prepare individual LCD for each of a number of systems that are developed to meet the Business Needs. The process continues for the system elements. ANSI/AIAA G-043A-2012 [13] identifies that the terms ‘concept of operations’ and ‘operational concept’ are often used interchangeably but notes 36 Requirements Practice that an important distinction exists because each has a separate purpose and is used to meet different ends. It is essential that these terms are used so that they are consistent with ANSI/AIAA G-043A-2012 and ISO/IEC/IEEE 29148 [14], as well as the way in which the terms are used in the US DoD and many other defence forces. ISO/IEC/IEEE 29148 describes the ConOps as: The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems, as black boxes, to forward the organization’s goals and objectives. The ConOps document describes the organization’s assumptions or intent in regard to an overall operation or series of operations of the business with using the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of the future business and systems, for the project to understand its background, and for the users of this International Standard to implement the stakeholder requirements elicitation. [15] ISO/IEC/IEEE 29148 describes the OpsCon as: A system OpsCon document describes what the system will do (not how it will do it) and why (rationale). An OpsCon is a user-oriented document that describes system characteristics of the to-be-delivered system from the user's viewpoint. The OpsCon document is used to communicate overall quantitative and qualitative system characteristics to the acquirer, user, supplier and other organizational elements. [16] The ConOps is developed by the organization leadership at the enterprise level.
Load more

Recommended publications
  • A System Model for Managing Requirement Traceability Matrices Via Statistical Artifact Change Analysis Benjamin J
    A System Model for Managing Requirement Traceability Matrices via Statistical Artifact Change Analysis Benjamin J. Deaver and LiGuo Huang, Southern Methodist University, Dallas Introduction and Motivation Requirement Traceability Matrix – Gantt Open Source Software Project The Value of the Requirements Traceability Matrix The system Requirement Traceability Matrix (RTM) is primarily used for ensuring Our initial dataset for evaluation is taken from the Gantt Open Source PROCEDURE Kannenberg et al identify the underlying necessity of the Requirements Traceability Matrix and the underlying effect on that all requirements are fulfilled by the system artifact deliverables and the Software Project (http://www.ganttproject.biz). The initial trace data 1. Identify the taxonomy of change for a given domain (Systems Engineering, project management, process visibility, verification and validation, as well as project maintainability. Over time, the management of change to deliverables with respect to impact on other systems. In has been provided to us by Dr. Alexander Egyed at the Institute for SoS Engineering, Software Engineering). the systems engineering and system of systems (SoS) engineering landscapes, the Systems Engineering and Automation at Johannes Kepler University. Requirements Traceability Matrix provides significant insight in to the internal workings of the relationships between RTM is a tool that is useful at time of creation, but requires constant maintenance in Additional traces of requirements to code for subsequent Gantt versions 2. Identify and classify changes between static versions of the product. requirements and deliverable artifacts. a frequently changing landscape to maintain the original level of validity. The are being created using similar methods to the original collections 3. Generate Requirements Trace Matrixes for each static version of the product dynamic nature of systems and SoS engineering landscapes requires that a RTM be performed by Dr.
    [Show full text]
  • Requirements Traceability Practices Guide
    CDC UNIFIED PROCESS PRACTICE GUIDE REQUIREMENTS TRACEABILITY Document Purpose The purpose of this document is to provide guidance on the project management practice of Requirements Traceability and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements. In addition, templates relevant to this practice are provided at the end of this guide. Practice Overview Requirements traceability is an activity that is one part of an overarching requirements management practice and extends from requirements definition through to implementation. Requirements tracing is used to ensure that each step of the product’s development process is correct, conforms to the needs of prior and next steps, and conforms to the defined requirements. Requirements tracing is a technique that helps to ensure that the project delivers what stakeholders expect. If applied correctly requirements tracing is a practice that can greatly increase the quality and reliability of a project’s final product while minimizing costly rework resulting from requirements errors. Requirements tracing defines the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through each step of the entire product’s life cycle. This is done by documenting and tracking traceability relationships between requirements. A traceability relationship is a dependency relationship between project and/or product elements. Similar to the way a dynamic project schedule may react to a change in one task, a change to a requirement element may also have a rippling effect on other elements. A well documented traceability relationship clearly defines requirement dependencies and allows for analysis of how changes in requirements affect other requirements and the project as a whole.
    [Show full text]
  • Non-Functional Requirements
    ® IBM Software Group Non-Functional Requirements Peter Eeles [email protected] IBM Software Group | Rational software Agenda Definitions Types of requirement Classifying requirements Capturing NFRs Summary IBM Software Group | Rational software Definitions Functional Requirement Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities. [Malan] Non-Functional Requirement Non-functional requirements include constraints and qualities. [Malan] [System] qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. [Malan] A constraint is a restriction on the degree of freedom we have in providing a solution. [Leffingwell] [Leffingwell] Managing Software Requirements – a Unified Approach, Dean Leffingwell and Don Widrig. [Malan] Defining Non-Functional Requirements, Ruth Malan and Dana Bredemeyer. IBM Software Group | Rational software Agenda Definitions Types of requirement Classifying requirements Capturing NFRs Summary IBM Software Group | Rational software Types of Requirement Use Cases Defines the behavior of the system from an external perspective System-Wide Requirements Legal and regulatory requirements, application standards, qualities that the system exhibits (such as usability, reliability, scalability, performance), operating system and environment requirements, compatibility requirements, and other design and implementation constraints Change
    [Show full text]
  • Understanding Document for Software Project
    Understanding Document For Software Project Sax burls his lambda fidged inseparably or respectively after Dryke fleeces and bobbles luxuriously, pleased and perispomenon. Laird is Confucian and sleet geometrically while unquiet Isador prise and semaphore. Dryke is doltish and round devilish as gyrational Marshall paraffin modestly and toot unofficially. How we Write better Software Requirement Specification SRS. Project Initiation Documents Project Management from. How plenty you punch an understanding document for custom project? Core Practices for AgileLean Documentation Agile Modeling. It projects include more project specification and understanding of different business analysts to understand. Explaining restrictions or constraints within the requirements document will escape further. FUNCTIONAL and TECHNICAL REQUIREMENTS DOCUMENT. Anyone preparing a technical requirement document should heed what. Most software makers adhere in a formal development process similar leaving the one described. Developers who begin programming a crazy system without saying this document to hand. Functional specification documents project impact through. Documentation in software engineering is that umbrella course that encompasses all written documents and materials dealing with open software product's development and use. Nonfunctional Requirements Scaled Agile Framework. We understand software project, she can also prefer to understanding! The project for understanding of course that already understand the ability to decompose a formal text can dive deep into a route plan which are the. Adopted for large mouth small mistake and proprietary documentation projects. Design Document provides a description of stable system architecture software. Process Documentation Guide read How to Document. Of hostile software Understanding how they project is contribute probably the. The architecture interaction and data structures need explaining as does around database.
    [Show full text]
  • Requirements Traceability Matrix Template
    Connecticut Department of Social Services Enterprise Program Management Office Requirements Traceability Matrix Purpose of the Requirements Traceability Matrix The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols. The traceability matrix is a tool both for the validation team to ensure that requirements are not lost during the validation project and for auditors to review the validation documentation. Information to Include The requirements traceability matrix is usually developed in concurrence with the initial list of requirements (either the User Requirements Specification or Functional Requirements Specification). As the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include the updated documents. Ideally, requirements should be traced to the specific test step in the testing protocol in which they are tested. How the RTM is used A requirements traceability matrix is used to check if the current project requirements are being met or to help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks. Change Impact Analysis – if a requirement is changing, trace links inform about related and dependent artifacts. These artifacts can easily be verified and if required, be adjusted. The probability to overlook related artifacts is reduced. Coverage Analysis – Traceability ensures that no requirements are overlooked. Especially when certifying safety-critical products it is necessary to demonstrate that all requirements are realized. Project Status Analysis – Tracking of the project status is possible: analyzing the traceability data allows the project manager to see the completion status of the requirements.
    [Show full text]
  • Requirements Engineering and Agile Methodology
    Requirements – Architecture - Agility R. Kuehl/J. Scott Hawker p. 1 R I T Software Engineering Requirements Engineering and Agile Processes (You may be thinking) Requirements engineering model as presented is not very agile Writing a SRS, etc. sounds like a classic heavy weight process It is! But, two points to consider as good software engineers: 1. Fit the software methodology and process to the problem 2. Agile processes do equivalent requirement engineering activities – still need requirements validated by stakeholders for success R. Kuehl/J. Scott Hawker p. 2 R I T Software Engineering Requirements and Agile Traditional approach – the requirements document Agile argument against tradition Communication gaps between authors and readers Change cycle is too long Challenging to capture the complete problem and system context Brain’s capacity to retain information Agile answer: Continuous collaboration with stakeholders . Workshops, conversation Stories (index cards) record conversations Are they the requirements? R. Kuehl/J. Scott Hawker p. 3 R I T Software Engineering Requirements Engineering in Agile Processes Where is the Knowledge? Requirements Eng. Agile Methodology 1. Elicitation 1. Stories 2. Iteration design, 2. Analysis customer collaboration 3. Specification 3. Stories, code, acceptance tests, unit 4. Validation tests 5. Management 4. Customer collaboration, acceptance tests 5. Planning cycle, frequent iterations R. Kuehl/J. Scott Hawker p. 4 R I T Software Engineering A Picture Worth a 1000 Words Requirements Waterfall Incremental Evolutionary “Classic” or agile style Design Always maps Construction (coding & testing) Deployment The Requirements Engineering Model The General Software Engineering Framework R. Kuehl/J. Scott Hawker p. 5 R I T Software Engineering R.
    [Show full text]
  • What Is a Requirement?
    What is a requirement? • May range from – a high-level abstract statement of a service or – a statement of a system constraint to a Software Requirements detailed mathematical functional specification • Requirements may be used for – a bid for a contract Descriptions and specifications • must be open to interpretation of a system – the basis for the contract itself • must be defined in detail • Both the above statements may be called requirements Example Example …… 4.A.5 The database shall support the generation and control of configuration objects; that is, objects which are themselves groupings of other objects in the database. The configuration control facilities shall allow access to the objects in a version group by the use of an incomplete name. …… 1 Types of requirements User requirements readers • Written for customers • Client managers – User requirements • Statements in natural language plus diagrams of the • System end-users services the system provides and its operational constraints. • Client engineers • Written as a contract between client and • Contractor managers contractor – System requirements • System architects • A structured document setting out detailed descriptions of the system services. • Written for developers – Software specification • A detailed software description which can serve as a basis for a design or implementation. System requirements readers Software specification readers • System end-users • Client engineers (maybe) • Client engineers • System architects • System architects • Software developers • Software developers 2 Functional requirements • Statements of services the system should provide, how the system We will come back to user should react to particular inputs and system requirements and how the system should behave in particular situations. Examples of functional Functional requirements requirements • Describe functionality or system services 1.
    [Show full text]
  • A Tutorial for Requirements Analysis
    Project Scope Management Prof. Dr. Daning Hu Department of Informatics University of Zurich Some of the contents are adapted from “System Analysis and Design” by Dennis, Wixom, &Tegarden. Course Review: What do Project Managers Manage? The Triple Constraint of Project Management •Scope &Quality •Time •Cost 2 Course Review: Project Objectives Scope & Quality (fitness for purpose) Budget (to complete it within the budget) Time (to complete it within the given time) It is clear that these objectives are not in harmony! 3 3 Course Review: Requirements Analysis and System Specification Why is it one of first activities in (software) project life cycle? Need to understand what customer wants first! Goal is to understand the customer’s problem. Though customer may not fully understand it! Requirements analysis says: “Make a list of the guidelines we will use to know when the job is done and the customer is satisfied.” Also called requirements gathering or requirements engineering System specification says: “Here’s a description of what the program/system will do (not how) to satisfy the requirements.” Distinguish requirements gathering & system analysis? A top-level exploration into the problem and discovery of whether it can be done and how long it will take. 4 Learning Objectives: Project Scope Management Explain what scope management is and the related processes Discuss methods for collecting and documenting requirements Explain the scope definition process and describe the contents of a Project Scope Statement Discuss the process of constructing a Work Breakdown Structure (WBS) using various approaches Explain the importance of scope verification and control and how to avoid scope problems 5 What is Project Scope Management? Scope refers to all the work involved in creating the products of the project and the processes used to create them.
    [Show full text]
  • Requirements Traceability and the Effect on the System Development Lifecycle (SDLC)
    Requirements Traceability and the Effect on the System Development Lifecycle (SDLC) by Glenn A. Stout (STOUT) DISS 725: Systems Development Process Spring Cluster, 2001 Research Paper 2 Glenn A. Stout (STOUT) Table of Contents Overview........................................................................................................................................3 Purpose..........................................................................................................................................3 Traceability....................................................................................................................................3 Traceability and Traceability Item Defined...............................................................................4 Traceability Links..................................................................................................................4 Traditional Requirements Gathering.............................................................................................5 In General..................................................................................................................................5 Engaging in the Practice of Tracing Requirements.......................................................................6 Software Requirements Specification (SRS).............................................................................6 Use Case Methodology..............................................................................................................7
    [Show full text]
  • Deriving DO-178C Requirements Within the Appropriate Level of Hierarchy
    ICSEA 2012 : The Seventh International Conference on Software Engineering Advances Deriving DO-178C Requirements Within the Appropriate Level of Hierarchy Jamie P. White Hassan Reza Department of Computer Science Department of Computer Science University of North Dakota University of North Dakota Grand Forks, USA Grand Forks, USA [email protected] [email protected] Abstract— In this paper, a set of criterion is proposed that assists an engineer in placing a derived requirement as defined by DO-178C in the proper document within the requirement document hierarchy. The proper documentation of derived requirements has historically posed some issues when it comes to requirements-based testing. For one thing, if the derived requirements are inappropriately documented, then it will be very difficult to establish traceability between individual requirements to the elements of design, implementation, and verification. Consequently, the lack of correlation between elements of requirements, design, code, and verification can jeopardize the safety of systems because it will be impossible to establish forward and backward traceability. To this end, the proposed criteria discussed in this work attempts to improve the visibility of derived requirements to prevent the unwanted consequences of masking required information from developers. Keywords-requirement traceability; requirements analysis; Figure 1. Example of a system requirement document hierarchy safety critical systems; RTCA/DO-178C; software testing; software design High-level requirements do not always contain sufficient details to describe the underlying requirement documents. As such it is necessary to create derived requirements (DR). A DR as defined by DO-178C [10] is a requirement that is not I. INTRODUCTION directly traceable to a higher-level source; it is inferred or An aircraft system is a complex system that is composed deduced from a specific source/user.
    [Show full text]
  • Requirement Analysis Fundamentals Requirements Analysis
    Requirements Analysis The process of Discovering, Refinement, Modeling and Requirement Analysis Specification in a software project. Involve both the Customer and System Engineer Fundamentals Allowing system engineer to achieve a set of objectives: Specify software function and performance Peter Lo Indicate software interface with other system elements Establish design constraints that the software must meet Provides the software designer with a representation of Information and Function that can be translated to Data, Architectural and Procedural Design. CS213 © Peter Lo 2005 1 CS213 © Peter Lo 2005 2 Requirements Analysis Software Requirement Analysis Preparation of the Software Specification: Divided into 5 main areas: It is a formal document that specifies in precise Problem Recognition terms the functional and performance requirements of the software. Evaluation and Synthesis Modeling Specification document in turn will allow the developer and customer to assess quality once Specification the software itself has been built. Review The software developer performing Requirement analysis would often be known as the Analyst CS213 © Peter Lo 2005 3 CS213 © Peter Lo 2005 4 Problem Recognition Evaluation and Synthesis Recognize the basic problem elements perceived Evaluate the flow and content of information by user and customer Define and elaborate all software functions Understand software behavior in the context of events that Understand software in the system context affect the system Define software scope Establish
    [Show full text]
  • Business to System Requirements Agile Mapping
    Business to System Requirements Agile Mapping Malgorzata Pankowska a Department of Informatics, University of Economics in Katowice, 1 Maja, Katowice, Poland Keywords: Business Requirement, System Requirement, Requirement Diagram, SysML, Archimate. Abstract: Business and Information Technology (IT) alignment methods and models have been developed for the last few years. Mainly, they focus on strategic alignment, however, the misunderstanding and lack of alignment are hidden in requirement mapping methods, tools, and approaches. Therefore, the paper aim is to present a model of business to system requirements mapping, based on the application of SysML and ArchiMate diagrams. The proposed approach is assumed to be considered as agile, because of its features. Finally, the approach is supported by online store case study. Beyond that, systematic literature review was done on SysML requirements engineering. 1 INTRODUCTION as for administrative sector units. As organizations cope with rapid changes in their business and IT Business requirements and IT requirements are environments, they need models and measures of accepted as aligned, if the IT functions are BITA, e.g., Strategic Alignment Model (SAM), implemented to achieve business objectives. Integrated Architecture Framework (IAF), According to Mekawy et al. (2009), business – IT Luftman’s Alignment Model (LAM), Reich and alignment is an ongoing process. However, this Benbasat Model (RBM), Sabherwal and Chan process is not only to be considered on strategic level, Alignment Model (SCAM), Hu Huang Alignment because each business change requires alignment Model (HHAM) (Mekawy et al.,2009). The main considerations on the operational level. The purpose problem is that models present high level discussions of this paper is not to evaluate the strategic alignment on BITA.
    [Show full text]