Sie sind auf Seite 1von 15

Requirements Engineering Overview

The Importance of Requirements:

 Identifying (some) requirements are the starting point for all software development
projects regardless of the development method being used.
 In conventional development, the cost of fixing problems after system delivery is high
(perhaps 100 times the cost of fixing an implementation error)
 Changes in requirements are inevitable
– as understanding of the requirements develops
– as the software development proceeds
– after the system is delivered (maintenance, evolution)

Why Requirements Engineering?

 Many projects have failed because of inadequate understanding of requirements


 Need for a systematic approach to specifying requirements, stages in the process:
– Feasibility Study :cost/benefit analysis for business & risk analysis prepared for management decision
making
- Requirements Elicitation and Analysis (requirements capture or discovery)
- finding out what is needed from the customers
– Specify Requirements for the customer (contract) and the system developer
– Validate Requirements - do the specified requirements actually define what the customer wants?

Software Requirements:
Requirements are descriptions of the services that a software system must provide and the
constraints under which it must operate Requirements can range from high-level abstract
statements of services or system constraints to detailed mathematical functional specifications.

Requirements Engineering is the process of establishing the services that the customer requires
from the system and the constraints under which it is to be developed and operated Requirements
may serve a dual function:
 As the basis of a bid for a contract
 As the basis for the contract itself

The requirements themselves are the descriptions of the system services and constraints that are
generated during the requirements engineering process.

Requirement: condition or capability needed by a user to solve a problem or achieve an


objective.

It may range from a high-level abstract statement of a service or of a system constraint to a


detailed mathematical functional specification.
- This is inevitable as requirements may serve a dual function
– May be the basis for a bid for a contract - therefore must be open to interpretation;
– May be the basis for the contract itself - therefore must be defined in detail;
– Both these statements may be called requirements.

Requirements Description:

 Each requirement deals with objects, states of objects, and changes in state or property
not implementation specific.
 Requirements state what, not how. The focus is on the customer and the problem,
not your solution.

Requirements abstraction:
“If a company wishes to let a contract for a large software development project, it must define its
needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be
written so that several contractors can bid for the contract, offering, perhaps, different ways of
meeting the client organization’s needs. Once a contract has been awarded, the contractor must
write a system definition for the client in more detail so that the client understands and can
validate what the software will do. Both of these documents may be called the requirements
document for the system.”

A Spiral Model of the requirements engineering process

The following concepts showing how requirements engineering dovetails with the overall
software engineering process.

Process models:
This subtopic is concerned with introducing a small number of generic process models. The
purpose is to lead to an understanding that the requirements process:
 is not a discrete front-end activity of the software life-cycle but rather a process that is
initiated at the beginning of a project but continues to operate throughout the life-cycle;
 the need to manage requirements under the same configuration management regime as
other products of the development process;
 Will need to be tailored to the organization and project context.
In particular, the subtopic shows how the activities of elicitation, analysis, specification,
validation and management are configured for different types of project and constraints. It
includes an overview of activities provide input to the process such as marketing and feasibility
studies.

Process actors:
This subtopic introduces the roles of the people who participate in the requirements engineering
process. Requirements engineering is fundamentally interdisciplinary and the requirements
engineer needs to mediate between the domains of the user and software engineering. There are
often many people involved besides the requirements engineer, each of whom have a stake in the
system. The stakeholders will vary across different projects but always includes users/operators
and customer (who need not be the same).
These need not be homogeneous groups because there may be many users and many customers,
each with different concerns. There may also be other stakeholders who are external to the
user’s/customer’s organization, such as regulatory authorities, whose requirements need to be
carefully analyzed. The system/software developers are also stakeholders because they have a
legitimate interest in profiting from the system. Again, these may be a heterogeneous group in
which (for example) the system architect has different concerns from the system tester.
It will not be possible to perfectly satisfy the requirements of every stakeholder and the
requirements engineer’s job is to negotiate a compromise that is both acceptable to the principal
stakeholders and within budgetary, technical, regulatory and other constraints. A prerequisite for
this is that all the stakeholders are indentified, the nature of their ‘stake’ is analysed and their
requirements are elicited.

Process support and management.


This subtopic introduces the project management resources required and consumed by the
requirements engineering process. It’s principal purpose is to make the link from process
activities identified in Process models.
Process quality and improvement.
This subtopic is concerned with requirements engineering process quality assessment. Its
purpose is to emphasize the key role requirements engineering plays in terms of the cost,
timeliness and customer satisfaction of software products. It will help orient the requirements
engineering process with quality standards and process improvement models for software and
systems. This subtopic covers:
 requirements engineering coverage by process improvement standards and models;
 requirements engineering metrics and benchmarking;
 improvement planning and implementation;
Domain Understanding:

• Domain knowledge is characterized by a set of concepts and terminology understood by


practitioners in that area of expertise.
• It also includes an understanding of recurring problems and known solutions within the
domain.
• Knowledge from several domains is usually required to build a single product.
• For example, to build a distributed banking application, you would need knowledge of
banking practices, commercial bank information systems, workflow management,
database management systems, networking, and user interfaces
• The practice of understanding the relevant domains involves
• identifying the areas of expertise–domains–that are useful for building the product or
products under consideration
• identifying the recurring problems and known solutions within these domains
• capturing and representing this information in ways that allow it to be communicated to
the stakeholders and used and reused across the entire effort

To achieve domain understanding depends on these two factors:

• The depth of the organization's domain experience: Organizations that have deep
domain expertise frequently opt not to invest in a full-blown "formal" domain analysis to
model their understanding of the relevant domains. (For example, they may use a hybrid
approach that combines requirements gathering with use case modeling and commonality
and variability analysis.) Foregoing formal domain analysis allows them to move into
design more quickly or to perform some initial design activities (e.g., the investigation of
architectural patterns) in parallel with the analysis.
• The amount of resources that can be devoted to analysis: The time, money, and
people allocated to the analysis will determine the duration and scope of the analysis
activities. However that's not to suggest that more analysis is always better. In fact,
"analysis paralysis" is a risk associated with this.

Requirements completeness and consistency:


In principle, requirements should be both complete and consistent.
 Complete
– They should include descriptions of all facilities required.
 Consistent
– There should be no conflicts or contradictions in the descriptions of the system
facilities.

In practice, it is impossible to produce a complete and consistent requirements document.


Requirements Engineering Activities (Requirements Engineering Process) :

The activities involved in requirements engineering vary widely, depending on the type of
system being developed and the specific practices of the organization(s) involved. These may
include:
1. Requirements inception or requirements elicitation -

In requirements engineering, requirements elicitation is the practice of collecting the


requirements of a system from users, customers and other stakeholders. The practice is also
sometimes referred to as requirements gathering.
The term elicitation is used in books and research to raise the fact that good requirements cannot
just be collected from the customer, as would be indicated by the name requirements gathering.
Requirements elicitation is non-trivial because you can never be sure you get all requirements
from the user and customer by just asking them what the system should do. Requirements
elicitation practices include interviews, questionnaires, user observation, workshops,
brainstorming, use cases, role playing and prototyping. Before requirements can be analyzed,
modeled, or specified they must be gathered through an elicitation process. Requirements
elicitation is a part of the requirements engineering process, usually followed by analysis and
specification of the requirements. Commonly used elicitation processes are the stakeholder
meetings or interviews. For example, an important first meeting could be between software
engineers and customers where they discuss their perspective of the requirements.
2. Requirements identification - identifying new requirements

3. Requirements analysis and negotiation - checking requirements and resolving stakeholder


conflicts .Requirements analysis in systems engineering and software engineering, encompasses
those tasks that go into determining the needs or conditions to meet for a new or altered product,
taking account of the possibly conflicting requirements of the various stakeholders, analyzing,
documenting, validating and managing software or system requirements. Requirements analysis
is critical to the success of a systems or software project. the requirements should be ocumented,
actionable, measurable, testable, traceable, related to identified business needs or opportunities,
and defined to a level of detail sufficient for system design.
4. Requirements specification (software requirements specification)- documenting the
requirements in a requirements document.

A software requirements specification (SRS), a requirements specification for a software system,


is a complete description of the behavior of a system to be developed and may include a set of
use cases that describe interactions the users will have with the software. In addition it also
contains non-functional requirements. Non-functional requirements impose constraints on the
design or implementation (such as performance engineering requirements, quality standards, or
design constraints).
The software requirements specification document enlists all necessary requirements that are
required for the project development. To derive the requirements we need to have clear and
thorough understanding of the products to be developed. This is prepared after detailed
communications with the project team and customer.
The SRS may be one of a contract deliverable data item descriptions or have other form of
organizationally-mandated content.
5. System modeling - deriving models of the system, often using a notation such as the unified
modeling language

Unified modeling language (UML) is a standardized ,general-purpose modeling language in the


field of software engineering. The unified modeling language includes a set of graphic notation
techniques to create visual models of object-oriented software-intensive systems.
The unified modeling language was developed by Grady Booch, Ivar Jacobson and James
Rumbaugh at rational software in the 1990s. It was adopted by the object management group
(omg) in 1997, and has been managed by this organization ever since. In 2000 the unified
modeling language was accepted by the international organization for standardization (ISO) as
industry standard for modeling software-intensive systems.
6. Requirements validation - checking that the documented requirements and models are
consistent and meet stakeholder needs

7. Requirements management - managing changes to the requirements as the system is


developed and put into use

Requirements management is the process of documenting, analyzing, tracing, prioritizing and


agreeing on requirements and then controlling change and communicating to relevant
stakeholders. It is a continuous process throughout a project. A requirement is a capability to
which a project outcome (product or service) should conform.

Stakeholders:

End Users are the drivers of the system using transactions to input data and creating documents to
run the business.
The Steering Committee (Group) is a group of business and project directors who have responsibility
for governing the project and providing high level direction.
Business Managers are senior representatives of the businesses areas affected by the new system.
They primarily provide resources and users to support the project.
Reporting Users (for example, Cost Center Managers) will use the system on an occasional basis to
produce reports.
Indirect Users are users that may not be going live in the system but are affected by other areas in terms
of procedural or more indirect change.
Expert Users are representatives from the business areas either full or part time on the project who
provide business input to the project. This includes involvement in design decisions and transferring
knowledge gained to users during training after support after Going Live and support.
The Project Team includes full time personnel who perform project activities including consultants and
people seconded from the businesses.
Customers and Suppliers are those external groups affected by the new system in terms of changes to
procedures, systems and /or external documents (such as Invoices).
Client: who is it being built for
Customer: who will buy it
Users: who will operate it, with what abilities
Domain experts: who is familiar with the problem
Marketing: who knows what the customers will need
Lawyers and auditors: who know the relevant law and standard practices
Software engineers: who will build the system

Roles:

Project Manager – a person in a team who will control the projects performed by your software
development team. He will follow the execution of the software project, control time and budget. He
should be organized himself and have excellent organizational skills. He is responsible for the software
team’s activity, and project accounting.

Business Analyst - a person in a team who will deal with customers and specify the direction to the
software roject. This person should analyze the requirements, work out the project strategy, write
documentation and lead the project to the successful completion. He should posses technical, managerial
and creative skills.

Software Architect – a person in a team who will develop the design of the software product taking into
account customer’s requirements. This person is not only a skillful software developer. Design Architect
is a "guru" who is able to work out software architecture for any complex system.

Designer – a creative person who is responsible for product look-and-feel taking into account customer’s
requirements. He should be a ‘hybrid’ designer who doesn’t strain at Photoshop and can write CSS-code.
He should be familiar with visual design as well as with web standards, should be a professional in
usability, universal design, accessibility, etc.

Software Developer – a person in a team who will develop the product. Software Developer should be an
expert in various spheres of software development (mobile application development, web application
development) and should study all the time to improve his knowledge and competence. But at the same
time, he should be a good team player.

Software Tester – a person who will test the software during the course of software development. He
should be familiar with various techniques and methods of software testing (black box testing, smoke
testing, etc) and should very patient.

In the dedicated software development team, every member should understand what other members are
doing, should be ready to take some of their tasks in case of necessity, should be a good communicator
(should be ready to take part in meetings with customers and negotiate some issues). Only in
collaboration the success is guaranteed.
In Addition:
Systems Analyst -- analyzes requirements for an application
Software Architect – designs the overall structure of the application
Software Network Specialist – LAN/WAN Network design, installation, maintenance
Software Programmer – implements the design using software development tools, COTS
software products, and computer languages
Software Systems Administrator – administers user accounts, technology refreshment,
software deployment to users, software problem solvers
Software Database Administrator – administers the database (installation, maintenance,
backup, refreshment)
Customer Support Engineer – solves customer, end-user problems with computer applications,
configuration (e.g. ISP)
Webmaster – designs, implements, and maintains a web site
Software Security Engineer – identification, authorization, authentication, data protection, data
integrity, CERT)
Software Project Manager –plan, organize, direct, coordinate, control a software project
(emphasis on risk management)
Software Configuration Manager – identify, change control, status accounting, audits and
reviews
Software Quality Manager/Engineer – software reliability modeling, statistical quality control,
defect analysis

Requirements Properties:

 Correct– Match clients desires


 Consistent– Do not conflict with each other
 Complete– Capture all of the clients desires
 Unambiguous– Cannot be misinterpreted
 Feasible– Possible
 Relevant– Pertain to the system at hand
 Verifiable– Can test and arrive at yes or no
 Traceable– Each has a documented origin approved by client

Types of Requirement:
User requirements
• Statements in natural language plus diagrams of the services the system provides
and its operational constraints. Written for customers
System requirements
• A structured document setting out detailed descriptions of the system services.
Written as a contract between client and contractor
Software specification
• A detailed software description which can serve as a basis for a design or
implementation. Written for developers

Requirements document structure:


Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index

Notations :

A notation is a representation scheme (or modeling language) for expressing any of the things
we want to study in RE. Examples include: dataflow diagrams, the Unified Modelling Language
UML (which is really a set of notations), predicate calculus, and even natural language.
Techniques
A technique describes how to perform a particular technical activity, and, if appropriate, how to
use a particular notation as part of that activity. The techniques we describe in this book cover
the basic skills of the requirements analyst. Examples include: interviewing, calculating return on
investment, use case diagramming, and conducting an inspection. Note that techniques generally
do not have proper names –they tend to be generic building blocks for more specific methods
and processes.
Methods
A method is a prescription for how to perform a related collection of technical activities,
especially where a set of techniques and notations are needed. A method offers guidance for how
to use the notations and techniques together to achieve a particular goal. Methods tend to be
specific in their applicability: for example they concentrate on a particular type of modeling, or a
particular type of application.
Examples include Systems Analysis and Design Technique (SADT), Object Modelling
Technique (OMT), the goal modelling method KAOS, and the Rational Unified Process (RUP).
Note that methods tend to have proper names, given to them by whoever invented them. Note
also that their names may include words like‘technique’ and ‘process’ – don’t be fooled, they are
all methods really!
Process Models
A Process Model is an abstract description of how a particular organisation normally conducts a
collection of activities, focusing on resource usage and dependencies between activities. The
difference between methods and process models is that methods focus on technical activities (i.e.
the content of activities), whereas process models concentrate on management of activities (i.e.
how activities can be measured and improved). Hence, technical staff tends to be more interested
in methods, while managers tend to be more interested in process models. Process models are
usually developed within particular development organizations to capture successful processes so
that they can be reused (and improved) from one project to another.
Processes
A Process is an enactment of a process model, describing the behaviour of one or more agents
and their management of resources. The process model describes what should happen; a process
is what actually happens on a particular project.
Requirements Elicitation:

Artifact-driven elicitation techniques


– Background study
– Data collection, questionnaires
– Repertory grids, card sorts for concept acquisition
– Scenarios, storyboards for problem world exploration
– Prototypes, mock-ups for early feedback
– Knowledge reuse: domain-independent, domain-specific

Stakeholder-driven elicitation techniques


– Interviews
– Observation and ethnographic studies
– Group sessions
-workshops
-Questionnaire
-Prototypes
-Brainstorming

Requirements Engineering Framework:


The framework defines:

 Four facets of the system context: the subject, the usage, the IT system, and the
development facets
 Three core requirements engineering activities: documentation, elicitation, and
negotiation
 Two cross-sectional activities: validation and management
 Three kinds of requirements artefacts: goals, scenarios, and solution-oriented
Requirements

Goal of Requirements Engineering: Establishing a Vision in Context.


Our requirements engineering framework defines the major structural elements of a
requirements engineering process required for establishing a vision within an existing context.
The framework consolidates various research results which have been developed based on
problem statements elicited from industrial practice and which have been successfully validated
and transferred to industry.

The framework consists of the following main building blocks:


-System context: The framework structures the system context into four parts: the Four context
facets subject, the usage, the IT system, and the development facet.
-Three core requirements engineering activities: The three core requirements engineering
activities (elicitation, documentation, and negotiation) are performed and negotiation
Iteratively in order to establish the vision within the existing context.
-Two cross-sectional activities: The two cross-sectional activities of validation and Validation
and management support the core activities and secure the results of requirements management
Engineering.
-Requirements artifacts: Our framework distinguishes three essential types of requirements
artefacts: goals, scenarios, and solution-oriented requirements.
Subject facet: The subject facet includes the objects and events in the system This includes, for
example, objects and events that the system must store or process information about. In other
words, information about the objects and events in the subject facet must be represented in the
system. The objects of interest can be tangible as well as intangible objects. For instance, a
software component that measures the speed of a vehicle requires a representation of the
intangible object “speed” within the component. The subject facet also includes aspects that
influence the representation of information about the objects and the events in the system, such
as laws that forbid or regulate the recording of certain types of data within a software-intensive
system, or laws which restrict the accuracy of the recorded data or the frequency of updating the
data.
Systemusage _ Usage facet: A software-intensive system is used by people or other software
intensive systems in order to achieve a goal or to accomplish a certain task. Theusage facet
comprises all aspects concerning the system usage by people and othersystems. This includes,
for example, the various usage goals which exist, desiredworkflows, different user groups with
specific characteristics, different interaction models with different associated interfaces as well
as laws and standards restricting or influencing the system usage.
IT system facet: The system to be developed is eventually deployed into an IT system nvironment
Existing IT infrastructure, which typically comprises existing software-intensive systems as well
as existing hardware and software platforms, communication network(s), peripheral devices, and
other hardware and software components used. The IT system facet comprises all aspects of the
operational and technical environment including policies and strategies defining restrictions
or guidelines for the use of any type of technology or operational environment. All these aspects
of the technical and operational environment, as well as the constraints resulting from them,
influence the definition of the system requirements. For example, the IT strategy might prescribe
the communication protocol to be used, which obviously influences the communication
requirements defined for the system, or the software platform might predefine a set of supported
operating systems which in turn influences the defined requirements.
_ Development facet: The development facet comprises all aspects of the context concerning the
development process of the system. This includes process guide- process lines and constraints,
development tools, quality assurance methods, maturity models, quality certifications, and other
means or techniques for ensuring the quality (e.g. safety or security) of a software-intensive
system. Each aspect of the development facet may be restricted by the client or by certain laws
and standards.For instance, the client may demand that only certified tools are used during
system development, or a standard might require that the system fulfils certain test criteria.
The Core Activities:
Documentation
Compliance with The focus of the documentation activity is the documentation and specification
of the documentation and specification rules elicited requirements according to the defined
documentation and specification rules.
The documentation activity thus distinguishes the following sets of rules:
-General documentation rules: These rules apply to all kinds of information to be documented
such as interview and meeting protocols, information about the context or decisions and
rationale. These rules define, for instance, the document layout, required document headers, and
required document management information such as authors or a version history.
- Documentation rules: These rules apply to each requirement documented at different
stages of the requirements engineering process. The rules aim to ensure a sufficient quality of the
documentation of the requirements mainly for use in other requirements engineering activities
(e.g. negotiation or validation) while at the same time keeping the documentation effort low.
Documentation rules may, for instance, prescribe a specific template to be used for documenting
the requirements.
-Specification rules: These rules apply to all requirements which are included in the
requirements specification. The specification rules aim to ensure high quality of the specified
requirements which are used in the subsequent development activities as key input or might be
part of contracts. The specification rules may prescribe, for instance, the use of syntactic
requirements patterns or a requirements specification

Elicitation
The goal of the elicitation activity is to improve the understanding of the requirements, i.e. to
achieve progress in the content dimension. During the elicitation dimension activity,
requirements are elicited from stakeholders and other requirement sources. In addition, new and
innovative requirements are collaboratively developed. The requirement sources relevant for the
system are not always known at the beginning of the process. An essential task of the elicitation
activity is therefore the systematic identification of relevant requirement sources. Relevant
requirement sources include the stakeholders involved in the process, existing documentation,
and existing predecessor systems. Requirements are elicited, for example, by interviewing
the stakeholders or by analysing existing documents and systems. In addition, innovative
requirements (which can typically not simply be elicited from a requirement source) are
developed in a collaborative and creative process. The development of innovative requirements
can, for example, be supported by applying creativity techniques such as brainstorming.
Negotiation
Individual, conflicting The system has to fulfil the needs and wishes of different stakeholders.
Obviously,stakeholder opinions the needs and wishes of the different stakeholders can vary.
Each stakeholder has his/her own view about the system to be developed. The different opinions
of the stakeholders can be in conflict with one another. The goal of the negotiation activity is
therefore twofold: First, all conflicts between the viewpoints of the different stakeholders have to
be detected and made explicit.Second, the identified conflicts should be resolved (as far as
possible). Depending on the cause of the conflict, different strategies can be applied for resolving
it. At the beginning of the requirements engineering process, typically the viewpoints of the
different stakeholders differ significantly. Ideally, at the end of the requirements engineering
process, the negotiation activity has identified and resolved all conflicts which exist between the
different stakeholders involved.

Two Cross-Sectional Activities


Besides the three requirements engineering core activities, two cross-sectional activities
significantly influence the requirements engineering process. The cross-sectional
activities support the three core activities and secure the results of requirements engineering.
The two cross-sectional activities are described in the following sub-sections
Validation
The validation of the requirements artifacts aims at detecting defects in the requirements. Only
requirements with high quality provide a sound basis for the architectural design, the
implementation of the system, and the development of test artifacts. Defects in requirements
entail defects in the architecture, in the implementation, and in test artifacts.

Management
This activity comprises the management of the requirements artifacts throughout the system
lifecycle.
_ Management of the activities
_ Observation of the system context

The Three Kinds of Requirements Artifacts


Goals
Requirements engineers need to understand the stakeholders’ intentions with regard to the
system to be developed. We define a goal (in requirements engineering) as follows:
Definition D
A goal is an intention with regard to the objectives, properties, or use of the system.
Goals have a prescriptive nature, i.e. a goal states what is expected or required from the system.
Thereby, goals differ from descriptive statements such as statements about the domain of the
system (e.g. the description of a physical law).
Scenarios
Examples of system usage: A scenario typically documents a concrete example of system usage.
It thus illustrates the fulfilment (or non-fulfilment) of a goal (or set of goals). Thus, a scenario
describes a concrete example of either how the system satisfies a goal or how it fails to satisfy a
goal. A scenario may define an interaction sequence at different levels of abstraction. For
example, a scenario can describe the interactions in detail and thus very close to reality or only
document the essential interactions. We define a scenario as follows:
Scenario
A scenario describes a concrete example of satisfying or failing to satisfy a goal(or set of goals).
It thereby provides more detail about one or several goals. A scenario typically defines a
sequence of interaction steps executed to satisfy the goal and relates these interaction steps to the
system context.

Solution-Oriented Requirements
Solution-oriented requirements define the data perspective, the functional perspective, and the
behavioural perspective on a software-intensive systems.
In contrast to goals and scenarios, which should be defined fairly independently from a specific
and intended solution, the definition of solution-oriented requirements often implies a conceptual
(or logical) solution for the system.

Das könnte Ihnen auch gefallen