jump to navigation

Requirements Engineering August 26, 2005

Posted by Coolguy in Business Analysis.
Tags:
trackback

Overview

  • The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended.
  • Broadly speaking, software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation.
  • There are a number of inherent difficulties in this process. Stakeholders (including paying customers, users and developers) may be numerous and distributed.
  • Their goals may vary and conflict, depending on their perspectives ofthe environment in which they work and the tasks they wish to accomplish.
  • Their goals may not be explicit or may be difficult to articulate, and, inevitably, satisfaction of these goals may be constrained by a variety of factors outside their control.
  • RE plays an important role in the management of change in software development.
  • Nevertheless, the bulk of the effort of RE does occur early in the lifetime of a project, motivated by the evidence that requirements errors, such as misunderstood or omitted requirements, are more expensive to fix later in project lifecycles
  • Before a project can be started, some preparation is needed. such as context and groundwork.
  • Context: RE is actually performed in a variety of contexts, including market-driven product development and development for a specific customer with the eventual intention of developing a broader market. The type of product will also affect the choice of method: RE for information systems is very different from RE for embedded control systems, which is different again from RE for generic services such as networking and operating systems.
  • Groundwork: For groundwork, some assessment of a project’s feasibility and associated risks needs to be undertaken, and RE plays a crucial role in making such an assessment.
  • It is often possible to estimate project costs, schedules and technical feasibility from precise specifications of requirements. It is also important that conflicts between high-level goals of an envisioned system surface early, in order to establish a system’s concept of operation and boundaries. Of course, risk should be re-evaluated regularly throughout the development lifetime of a system, since changes in the environment can change the associated development risks.

Eliciting Requirements

  • One of the most important goals of elicitation is to find out what problem needs to be solved, and hence identify system boundaries.
  • These boundaries define, at a high level, where the final delivered system will fit into the current operational environment.
  • Identifying and agreeing a system’s boundaries affects all subsequent elicitation efforts.
  • The identification of stakeholders and user classes, of goals and tasks, and of scenarios and use cases all depend on how the boundaries are chosen.
  • Identifying stakeholders – individuals or organisations who stand to gain or lose from the success or failure of a system – is also critical. Stakeholders include customers or clients (who pay for the system), developers (who design, construct and maintain the system), and users (who interact with the system to get their work done).
  • For interactive systems, users play a central role in the elicitation process, as usability can only be defined in terms of the target user population.
  • Users themselves are not homogeneous, and part of the elicitation process is to identify the needs of different user classes, such as novice users, expert users, occasional users, disabled users, and so on
  • Goals denote the objectives a system must meet. Eliciting high level goals early in the development process is crucial. However, goal-oriented requirements elicitation is an activity that continues as development proceeds, as high-level goals (such as business goals) are refined into lower-level goals (such as technical goals that are eventually operationalised in a system).
  • Eliciting goals focuses the requirements engineer on the problem domain and the needs of the stakeholders, rather than on possible solutions to those problems.
  • It is often the case that users find it difficult to articulate their requirements. To this end, a requirements engineer can resort to eliciting information about the tasks users currently perform and those that they might want to perform
  • These tasks can often be represented in use cases that can be used to describe the outwardly visible requirements of systems
  • More specifically, the requirements engineer may choose a particular path through a use case, a scenario, in order to better understand some aspect of using a system

Elicitation techniques

  • The choice of elicitation technique depends on the time and resources available to the requirements engineer, and of course, the kind of information that needs to be elicited.
  • Traditional techniques include a broad class of generic data gathering techniques. These include the use of questionnaires and surveys, interviews, and analysis of existing documentation such as organisational charts, process models or standards, and user or other manuals of existing systems.
  • Group elicitation techniques aim to foster stakeholder agreement and buy-in, while exploiting team dynamics to elicit a richer understanding of needs. They include brainstorming and focus groups, as well as RAD/JAD workshops (using consensus-building workshops with an unbiased facilitator)
  • Prototyping has been used for elicitation where there is a great deal of uncertainty about the requirements, or where early feedback from stakeholders is needed. Prototyping can also be readily combined with other techniques, for instance by using a prototype to provoke discussion in a group elicitation technique, or as the basis for a questionnaire or think-aloud protocol.
  • Model-driven techniques provide a specific model of the type of information to be gathered, and use this model to drive the elicitation process. These include goal-based methods, such as KAOS and I* , and scenario-based methods such as CREWS.
  • Cognitive techniques include a series of techniques originally developed for knowledge acquisition for knowledge-based systems. Such techniques include protocol analysis (in which an expert thinks aloud while performing a task, to provide the observer with insights into the cognitive processes used to perform the task), laddering (using probes to elicit structure and content of stakeholder knowledge), card sorting (asking stakeholders to sort cards in groups, each of which has name of some domain entity), repertory grids (constructing an attribute matrix for entities, by asking stakeholders for attributes applicable to entities and values for cells in each entity).
  • Contextual techniques emerged in the 1990’s as an alternative to both traditional and cognitive techniques. These include the use of ethnographic techniques such as participant observation. They also include ethnomethodogy and conversation analysis, both of which apply fine grained analysis to identify patterns in conversation and interaction



More: http://en.wikipedia.org/wiki/Requirements_analysis

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: