Requirements reality

Requirements Engineering Processes, York EngD Programme, 2010 Slide 1
Requirements reality
Prof Ian Sommerville

Objectives
• To introduce the activities in requirements
engineering processes
• To discuss the reasons why these formal
representations rarely match the actual processes
used in organisation

RE process perspectives
Different views of requirements engineering processes

Perceptions of requirements
engineering
• Requirements engineering (RE) means different things to
different people
– It’s about problem analysis, and
– It’s about solution specification, and
– It’s the baseline for design, and
– It’s what you do at the start of the life-cycle.
• RE is all of these things so, as a consequence, there cannot
be a single, definitive RE process
• RE processes vary dramatically depending on the type of
system being developed and the maturity of the organisation
procuring the system

Goals of requirements
engineering
• Specify a product that satisfies the stakeholders
and constraints
• Specify how that satisfaction is to be verified
• Enable project planning and cost estimation
• Manage change
• Write a description of the requirements in a form
that is suitable for the customer for the system and
for the system developer

RE process interactions
Requirements engineering
System design
System acquisition

A staged model of a requirements
engineering process

A spiral view of the RE process

Process presentation
• These are textbook models of processes
• A small number of organisations, mostly from the
aerospace and defence sectors, have formal
requirements engineering processes but, in most
cases, requirements engineering is an ad hoc activity
• Process models are helpful for talking about
requirements engineering activities but very different
from the reality of real requirements engineering

Problems with formal processes
• They do not differentiate between different kinds of
organisation and different kinds of product
• They assume that stakeholders in a system are
willing to engage in an RE process
• They fail to take into account the human, social,
organisational and political issues that affect the
system requirements

The world is a diverse place

Is the product...
• An information system?
– Understanding the organisational environment is crucial;
– The organisation may change radically;
• An embedded or hybrid system?
– Operational environment needs to be understood;
– Solution architecture fixed early and hard to change;
– Production problems tend to migrate to the software.
• A custom-built system or a software product
– Do customers for know what their requirements are?
– Who supplies the requirements for a software product?

Is the process...
• Customer-driven?
– Customer is principal stakeholder;
– Typically a document-driven process.
• Market-driven?
– Time-to-market is the dominant constraint;
– Developer is principal stakeholder;
– Driven by product vision for first release. Subsequent
releases need to balance developer’s strategic goals and
customers’ requirements.

Is the customer…
• Homogeneous?
– Need to understand their business and strategic objectives.
• Heterogeneous?
– Need to trade off conflicting requirements, This is the
normal situation.
• Merely potential?
– Need a proxy to represent the actual customer

Has the developer...
• A document culture?
– Documentation may be an overhead for small start-ups - but
a creeping requirement as product and customer base grows.
• A quality culture?
– RE ‘products’ perceived to have only an indirect relationship
to software products;
– Classical view of quality conflicts with short development
cycles.
• An agile culture?
– No experience of dealing with requirements documents but
works on the basis of prototyping and rapid evolution

Is the deployment
environment...
• An existing environment with established processes
and equipment?
– How should the system integrate with the existing
equipment? Will existing processes be resistant to change?
• Flexible and geared to change?
– Are the people in the environment used to change or will they
resist the system?
– Is the management tradionally hierarchical?
• Disciplined?
– Do the people in the environment work according to a
process or do they set their own tasks?

Stakeholder engagement

Stakeholder consultation
Requirements
engineering is
about talking
with people
who are
system
stakeholders
to understand
what they
need from a
system

The stakeholder illusion
• Can ‘typical’ stakeholder representatives be
identified?
– If there are thousands of potential users, how can you find
those that are representative?
– Do you wish to represent the early adopters, the majority or
the system laggards?
• Who are the key stakeholders?
– Key stakeholders are often not system users but people who
have the authority to accept or reject system proposals
– They may do so because the system presents risks for them
although it may considerably improve some other processes

• Do they want a new system?
– In many cases, these are not end-users so do not understand
the problems and issues that may arise with an existing
system
• Do they have the time or inclination to get involved in
a requirements engineering process?
– People are busy – they don’t care

People and politics

The world is not a rational place
• Requirements engineering (like all engineering) is
founded on the premise that the world is a rational
place and that decisions will primarily be driven by
technical considerations
• This is more true for engineering that is based on the
physical world – it is hard to argue against the Laws
of Physics
• BUT – requirements engineering takes place in the
world of humans, organisations and politics

The larger the system, the less
the technicalities matter

Human issues
• Do individuals or the organisation benefit from a
system?
• Will a system force people to change the ways that
they do their job?
• Will a system change the balance of power and
authority in an organisation?
• Will a system pose risks that might affect the position
of individuals in an organisation?
• Does a system have a significant learning overhead
for individuals?

Organisational issues
• Will the system require or promote changes to the
structure of an organisation?
• Will the system affect the power structure in an
organisation?
• Will the system require:
– More/fewer people
– More/less space
– More/less departmental budget

Political issues
• Who will take credit if the system is a success?
• Who will get the blame when a system fails? Will
there be an external perception of blame?
• Do the timescales for system
procurement/development/deployment fit in with the
likely times that people will remain in a job?
• Are there critical external factors that influence
system decision making?
• Will the system affect the relationships between
organisations?

The world changes

Requirements volatility
• Requirements encapsulate the relationship between
a system and its operating, organisational and
political environment
• The environment is constantly changing as
stakeholders change, competitive products are
introduced, organisational structures, policies and
procedures change, laws change, etc. etc.
• If requirements don’t change then the system will
become progressively less and less useful

Volatility measurement
RV = percentage of requirements that change
Number of days
Example – 10% of requirements change in a week so
RV = 1.45

• If the requirements volatility is too high, then is there
any point in having a detailed set of system
requirements?
• For example
– If 10% of the requirements change in a week and the
development schedule for a software element of system is 12
weeks, then over the development lifetime the requirements
will have completely changed.
• Problem in all areas – less so in large engineered
system but a particular problem for web-based
organisational systems used by professionals

What is the solution?
• Incremental requirements engineering
– Just enough RE to get started and continue throughout
development process
• Requires new contractual models for systems
engineering that are not based on a detailed
requirements specification?
• Problems
– Procurement legislation
– Organisational outsourcing
– Legal risks

Key points
• A staged requirements engineering process includes
a feasibility study, requirements elicitation and
analysis, requirements specification and
requirements management.
• Formal processes rarely represent requirements
reality
• Human, social, organisational and political factors
are the most significant influence on system
requirements, especially for LSCITS
• If requirements change very quickly, it may not be
sensible to have a detailed requirements document

Requirements reality

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a Requirements reality

Semelhante a Requirements reality (20)

Mais de Ian Sommerville

Mais de Ian Sommerville (20)

Último

Último (20)

Requirements reality