Software Requirements By Pete Sawyer

Software RequirementsBy Pete Sawyer Presented by Ehsan Ghaneie EEL6883 – Software Engineering II

Software Requirements • Software requirements concern the specification of software systems • Software systems are always derived from some business problem • They are always embedded in an operational context • They have interfaces to human users, business process elements, or other hardware/software systems

Software Requirements • Derivation of software requirements can rarely be isolated from underlying business problem • Software requirements are not a discrete area of software engineering • They are part of the system engineering process known as requirements engineering

Why is it important? • An effective RE process that minimizes occurrences of requirement errors is critical to success of any development project • The cost of rectifying errors in the requirements increases significantly as development proceeds

Requirements and Constraints • A Requirement defines a property or capability that the system must exhibit in order for it to solve the business problem for which it was conceived • Functional Requirements describe a function that the system must perform • Nonfunctional (Extra-Functional) Requirements describe the qualities of a system • How well the system operates within its environment • The quality of delivery of functional requirements • Some requirements are emergent properties and dependant on a wide range of factors some of which are hard to analyze and control • Satisfying such requirements depends upon how the whole system operates within its environment, and not just a particular system component

Requirements and Constraints • Requirements are specified at several points on a spectrum that ranges from those with a business focus to those with a technical focus • At the highest level are the goals of a system that set out in very broad strategic terms what is needed to solve some business problem • Identifying these needs usually motivates a development project

Requirements and Constraints • The next level of requirements define what must be observable in a black-box system that solves the business problem • These are called user requirements • Stakeholder requirements • System requirements • The technically focused requirements exist only to make it possible to satisfy the business focused ones • Constraints are like negative requirements and act to limit the set of possible solutions

Software Requirements • Requirements Engineering Process • Requirements Elicitation • Requirements Sources • Elicitation Techniques • Requirements Analysis • The System Boundary • Requirements Modeling • Derived Requirements • Requirements Attributes • Requirement Trade-offs • Software Requirements Specification • Requirements Validation • Requirements Management • Change Control • Version Control • Requirements Tracing • Status Tracking

Requirements Engineering Process • Is a process that must transform a business problem into a specification of the properties of a system that will provide an appropriate solution to the problem, through a set of activities

What are the activities? • The properties that the system must exhibit must be elicited • Elicited requirements must be subjected to analysis to establish a set of requirements that are correct, complete, and feasible • This set of requirements must be then recorded in a specification document that communicate the requirements to the people who will use them to develop the software

Requirements Engineering Process • The documented requirements must be then validated to ensure the software they specify will meet the needs of the people whom from the requirements were elicited • As development proceeds requirements need to be managed so that changed are controlled

Requirements Engineering Process • This process begins with scoping the system which involves understanding the underlying problem that the system is to address, identifying the goals of the system, and outlining how it will operate in its environment • Then the system requirements are elicited from their sources, analyzed, and validated • For each software component, further analysis of the allocated requirements is used to derive the requirements that fully specify the software

Requirements Engineering Process • It is not always possible to capture all the requirements • If the product’s environment is volatile, the requirements will also be volatile • When software products are developed to compete in the market, the requirements are likely to evolve with the market • Other factors such as meeting the release dates can also affect the RE process

Requirements Elicitation • Requirements elicitation is the process of discovering the requirements • The requirements engineer must identify the sources of requirements, collect information about the problem from these sources, and synthesize requirements from this information

Requirements Elicitation • Requirements elicitation is not a passive learning process about what stakeholders want • Instead, the requirements engineer must dig beneath the stakeholders’ accounts for their concerns, needs, and desires to uncover the underlying business problem

Requirements Sources • First step is to identify stakeholders • Large systems have many stakeholders and they are usually the main sources of requirements • Stakeholders must be classified to ensure no significant sources of requirements are overlooked • Role of each stakeholder must be understood and a representative must be selected to work with the requirement engineer • Since these people are usually busy people, it is important to find people who are motivated to act as “product champions”.

Requirements Sources • Stakeholders have viewpoints • These are partial views of the problem domain which are colored by the stakeholders’ own role and experience • This means requirements might be inconsistent • The requirements engineer must recognize the scope and limitations of stakeholders’ viewpoints to help resolve inconsistencies and apply priorities

Requirements Sources • Stakeholders are not the only sources of requirements • Requirements and constraints might come from the application domain or from business rules that exists in the organizational environment • Key requirements therefore might be hidden in documents, interface specifications, and the experience of domain experts

Requirements Sources • It is important to identify the key requirements that are derived from the application domain and therefore domain expertise plays a crucial role in successful requirements elicitation • Although stakeholders might be good domain experts, but they’re not good candidates mostly because of their view points and often they find it difficult to articulate the tacit knowledge that underpins how the domain operates • If the requirement engineer doesn’t have sufficient domain expertise and can not be trained within a reasonable time, domain experts might have to be brought in from elsewhere to play an active role in the RE process

Elicitation Techniques • Once sources are identified, the process of collecting knowledge about the problem begins • This starts with understanding the stakeholders’ role in the problem domain, or basically understanding their jobs • The requirements engineer must find an effective way to get the stakeholders analyze what they need

Elicitation Techniques • Users’ scenarios provide a valuable tool for socio-technical systems • The requirements engineer asks the users to identify their main tasks, each consisting of a sequence of events, noting preconditions, post conditions, communication with colleagues, and other events that are involved in the task

Elicitation Techniques • Elicitation may proceed as a series of interviews with individual stakeholders • It is helpful to get them all together (Elicitation workshops) especially once the problem is understood. This helps resolving inconsistencies • But elicitation workshops are not always the best solution as some people may be unwilling or unable to participate or may find scenarios awkward

Requirements Analysis • Requirements Analysis is about understanding the problem and synthesizing a set of requirements that specify the best solution • Analysis is needed to help deepen the understanding of the problem and what is required, and to detect and resolve problems such as inconsistencies and incompatibility with the requirements • Elicitation and analysis are closely coupled

Requirements Analysis • Requirements Analysis will result in a baseline set of requirements, meaning requirements that the system will implant • These are not necessarily everything the stakeholders asked for. • The requirements in the baseline should be necessary and sufficient

The System Boundary • Systems are developed to address some strategic goal or goals and these goals are first things that need to be identified • The scope of the project must be defined once the goals are identified • The scope must include a definition of the system boundaries meaning identifying what elements of the problem are going to be addressed by the proposed system

The System Boundary • Outside the system boundaries are the things in the system’s environment hat may impose requirements or constraints • Within the system boundary are all the aspects of the problem for which the proposed system will provide a solution

Requirements Modeling • Engineers use models to help make sense of complex information and visualize complex system properties • Requirements engineers construct models of the problem so they can discover suitable solution requirements • Models are also used to help describe the proposed system to help communicate with the developers • If the dynamic behavior of system can not be analyzed using static models, simulation can be used instead

Why derive more requirements? • The cost and technical implications of system requirements are often unclear and this makes them hard to assess and validate • The requirements elicited from the stakeholders will typically be expressed in terms of the application domain. The requirements needed by software developers are technical • The requirements need to be translated from domain-centric to software-centric, from abstract to technical • So it is usually helpful to elaborate the system requirements by deriving new requirements that focus on more detailed properties of the proposed system • One of the motives for deriving more detailed requirements is understanding the system implications • The other one is to provide enough details for the developers

Derived requirements • The derivation of requirements is not confined to functional requirements • High-level expressions of non functional requirements need to be quantified and transformed into a set of equivalent functional requirements • The requirements engineer must choose a suitable metric and specify how the system must score against this metric

Derived requirements • The derivation process should stop when the requirements are sufficiently specific for • the requirements engineer to be confident that the requirements are fully understood • the developers to commence solution design • Getting too detailed leads to premature design and constraining the design unnecessarily

Requirements Attributes • It is insufficient merely to record the statements of need that express the requirements • Requirements have a number of attributes that should be assigned values in order to ease their management • Some of these attributes are: • Identifier, source, date, rationale, type, priority, stability, verification procedure, and status

Requirement Trade-offs • Requirements from different stakeholders are valid but mutually inconsistent • Insufficient resources available to satisfy all the requirements • Stakeholders must be made aware of such conflicts and be explicitly involved in making the trade offs • Agreeing on requirements’ priorities helps the trade-off process • Achieving agreement is often easier if stakeholders are aware of each others’ concern

Software Requirements Specification • Projects may use up to three kinds of “specification” document at different stages of the RE process • Concept of Operations (ConOps) document sets out the projects vision and scope • System requirements specification defines the requirements for the whole system • Software requirements specification (SRS) specifies the requirements for a software component or subsystem

Software Requirements Specification • Each document has a different purpose • System requirements specification must be readable by the stakeholders to enable them to validate the requirements and approve them as the basis for subsequent development • The SRS, by contrast, is primarily a technical document aimed at the developers. It must specify the software completely and unambiguously

Requirements Validation • Requirements validation can be crudely characterized as ensuring correctness of the requirements • The set of requirements specified in the requirements specification must accurately reflect what is needed to solve the underlying business problem • This concerns not just the correctness of individual requirements, but the correctness, completeness, and consistency of the specification as a whole • The requirements must also conform to appropriate standards, guidelines, and conventions in order to ensure the readability, maintainability, consistency, and other important qualities of a specification document

Requirements Validation • In most cases, the requirements are validated statically • In some cases in which complex dynamic behavior is specified, the requirements may need to be validated dynamically using prototypes or simulations • This kind of validation is costly and it should be done well before the issue of the draft requirements specification document

Requirements Validation • Requirements reviews are a mechanism for validating requirements • Review panel must include both developer and stakeholder representatives • This task can be made easier by including checklists of things to look for

Requirements Validation • Another way to validate the requirements is to write test cases against the requirements • If it proves excessively hard to plan how a requirement can be verified then there is something wrong with the requirement • Although non functional requirements are inherently hard to verify, they must be verifiable if they are to serve any useful purpose

Requirements Validation • Once the requirements specification document has been validated and any necessary changed have been made, the requirements specification document will be “signed off” on • Although a formal “signing off” may not occur, it will considerably complicates the requirements management tasks

Software Requirements By Pete Sawyer

Software Requirements By Pete Sawyer

Presentation Transcript

Software Requirements

Software Requirements

Software Requirements

Software Requirements

Software Requirements

Software Requirements

By: Sawyer B.

Software Requirements

Software Requirements

Software Requirements

Software Requirements

by Pete Steeves

by Pete Steeves

Software Requirements

Software Requirements

Software Requirements

Software Requirements

by Pete Steeves

Software requirements

Software Requirements