Requirements engineering processes

• The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.
• However, there are a number of generic activities common to all processes
  • Requirements elicitation;
  • Requirements analysis;
  • Requirements validation;
  • Requirements management
• The requirements engineering process

• Requirements engineering
• 

• Feasibility studies
• A feasibility study decides whether or not the proposed system is worthwhile.
• A short focused study that checks
  • If the system contributes to organisational objectives;
  • If the system can be engineered using current technology and within budget;
  • If the system can be integrated with other systems that are used.
• Feasibility study implementation
• Based on information assessment (what is required), information collection and report writing.
• Questions for people in the organisation
  • What if the system wasn’t implemented?
  • What are current process problems?
  • How will the proposed system help?
  • What will be the integration problems?
  • Is new technology needed? What skills?
  • What facilities must be supported by the proposed system?
  • Elicitation and analysis
• Sometimes called requirements elicitation or requirements discovery.
• Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.
• May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
• Problems of requirements analysis
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may emerge and the business environment change.
• Process activities
• Requirements discovery
  • Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
• Requirements classification and organisation
  • Groups related requirements and organises them into coherent clusters.
• Prioritisation and negotiation
  • Prioritising requirements and resolving requirements conflicts.
• Requirements documentation
  • Requirements are documented and input into the next round of the spiral.
• Requirements discovery
• The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.
• Sources of information include documentation, system stakeholders and the specifications of similar systems.
• ATM stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators
• Viewpoints
• Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints.
• This multi-perspective analysis is important as there is no single correct way to analyse system requirements
• Types of viewpoint
• Interactor viewpoints
  • People or other systems that interact directly with the system. In an ATM, the customer’s and the account database are interactor VPs.
• Indirect viewpoints
  • Stakeholders who do not use the system themselves but who influence the requirements. In an ATM, management and security staff are indirect viewpoints.
• Domain viewpoints
  • Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standards for inter-bank communications.
• Viewpoint identification
• Identify viewpoints using
  • Providers and receivers of system services;
  • Systems that interact directly with the system being specified;
  • Regulations and standards;
  • Sources of business and non-functional requirements.
  • Engineers who have to develop and maintain the system;
  • Marketing and other business viewpoints.
• LIBSYS viewpoint hierarchy
• 

• Interviewing
• In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.
• There are two types of interview
  • Closed interviews where a pre-defined set of questions are answered.
  • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
• Interviews in practice
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.
• Interviews are not good for understanding domain requirements
  • Requirements engineers cannot understand specific domain terminology;
  • Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.
• Effective interviewers
• Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements.
• They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.
• Scenarios
• Scenarios are real-life examples of how a system can be used.
• They should include
  • A description of the starting situation;
  • A description of the normal flow of events;
  • A description of what can go wrong;
  • Information about other concurrent activities;
  • A description of the state when the scenario finishes.

• Use cases
• Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.
• A set of use cases should describe all possible interactions with the system.
• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.
• Article printing use-case
• 

• LIBSYS use cases
• 

• Print article sequence

• Print article sequence
• 

• Social and organisational factors
• Software systems are used in a social and organisational context. This can influence or even dominate the system requirements.
• Social and organisational factors are not a single viewpoint but are influences on all viewpoints.
• Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis.
• Ethnography
• A social scientists spends a considerable time observing and analysing how people actually work.
• People do not have to explain or articulate their work.
• Social and organisational factors of importance may be observed.
• Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.
• Focused ethnography
• Developed in a project studying the air traffic control process
• Combines ethnography with prototyping
• Prototype development results in unanswered questions which focus the ethnographic analysis.
• The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant.
• Ethnography and prototyping

§         Scope of ethnography

• Requirements that are derived from the way that people actually work rather than the way I which process definitions suggest that they ought to work.
• Requirements that are derived from cooperation and awareness of other people’s activities.
  • Requirements validation
• Concerned with demonstrating that the requirements define the system that the customer really wants.
• Requirements error costs are high so validation is very important
  • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
• Requirements checking
• Validity. Does the system provide the functions which best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and technology
• Verifiability. Can the requirements be checked?
• Requirements validation techniques
• Requirements reviews
  • Systematic manual analysis of the requirements.
• Prototyping
  • Using an executable model of the system to check requirements. Covered in Chapter 17.
• Test-case generation
  • Developing tests for requirements to check testability.
• Requirements reviews

• Regular reviews should be held while the requirements definition is being formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.
• Review checks
• Verifiability. Is the requirement realistically testable?
• Comprehensibility. Is the requirement properly understood?
• Traceability. Is the origin of the requirement clearly stated?
• Adaptability. Can the requirement be changed without a large impact on other requirements?
  • Requirements management
• Requirements management is the process of managing changing requirements during the requirements engineering process and system development.
• Requirements are inevitably incomplete and inconsistent
  • New requirements emerge during the process as business needs change and a better understanding of the system is developed;
  • Different viewpoints have different requirements and these are often contradictory.
• Requirements change
• The priority of requirements from different viewpoints changes during the development process.
• System customers may specify requirements from a business perspective that conflict with end-user requirements.
• The business and technical environment of the system changes during its development.
• Requirements evolution

• Requirements management planning
• During the requirements engineering process, you have to plan:
  • Requirements identification
    •  How requirements are individually identified;
  • A change management process
    • The process followed when analysing a requirements change;
  • Traceability policies
    • The amount of information about requirements relationships that is maintained;
  • CASE tool support
    • The tool support required to help manage requirements change;
• Traceability
• Traceability is concerned with the relationships between requirements, their sources and the system design
• Source traceability
  • Links from requirements to stakeholders who proposed these requirements;
• Requirements traceability
  • Links between dependent requirements;
• Design traceability
  • Links from the requirements to the design;

System modelling

• System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.
• Different models present the system from different perspectives
  • External perspective showing the system’s context or environment;
  • Behavioural perspective showing the behaviour of the system;
  • Structural perspective showing the system or data architecture.
• Model types
• Data processing model showing how the data is processed at different stages.
• Composition model showing how entities are composed of other entities.
• Architectural model showing principal sub-systems.
• Classification model showing how entities have common characteristics.
• Stimulus/response model showing the system’s reaction to events

3.5         Context models

• Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.
• Social and organisational concerns may affect the decision on where to position system boundaries.
• Architectural models show the system and its relationship with other systems
• The context of an ATM system

• Process models
• Process models show the overall process and the processes that are supported by the system.
• Data flow models may be used to show the processes and the flow of information from one process to another.
• Equipment procurement process
• 

3.6             Behavioural models

• Behavioural models are used to describe the overall behaviour of a system.
• Two types of behavioural model are:
  • Data processing models that show how data is processed as it moves through the system;
  • State machine models that show the systems response to events.
• These models show different perspectives so both of them are required to describe the system’s behaviour.
• Data-processing models
• Data flow diagrams (DFDs) may be used to model the system’s data processing.
• These show the processing steps as data flows through a system.
• DFDs are an intrinsic part of many analysis methods.
• Simple and intuitive notation that customers can understand.
• Show end-to-end processing of data.
• Order processing DFD
• 

• Data flow diagrams
• DFDs model the system from a functional perspective.
• Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system.
• Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment.
• Insulin pump DFD
• 

• State machine models
• These model the behaviour of the system in response to external and internal events.
• They show the system’s responses to stimuli so are often used for modelling real-time systems.
• State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.
• Statecharts are an integral part of the UML and are used to represent state machine models.
• Statecharts
• Allow the decomposition of a model into sub-models (see following slide).
• A brief description of the actions is included following the ‘do’ in each state.
• Can be complemented by tables describing the states and the stimuli
• Microwave oven model

• Microwave oven state description

• 
• Microwave oven stimuli

• Microwave oven operation

§        3.7       `       Semantic data models

• Used to describe the logical structure of data processed by the system.
• An entity-relation-attribute  model sets out the entities in the system, the relationships between these entities and the entity attributes
• Widely used in database design. Can readily be implemented using relational databases.
• No specific notation provided in the UML but objects and associations can be used.
• Library semantic model
• 
• Data dictionaries
• Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included.
• Advantages
  • Support name management and avoid duplication;
  • Store of organisational knowledge linking analysis, design and implementation;
• Many CASE workbenches support data dictionaries.
• Data dictionary entries
• 
  • Object models
• Object models describe the system in terms of object classes and their associations.
• An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object.
• Various object models may be produced
  • Inheritance models;
  • Aggregation models;
  • Interaction models.
• Object models
• Natural ways of reflecting the real-world entities manipulated by the system
• More abstract entities are more difficult to model using this approach
• Object class identification is recognised as a difficult process requiring a deep understanding of the application domain
• Object classes reflecting domain entities are reusable across systems
• Inheritance models
• Organise the domain object classes into a hierarchy.
• Classes at the top of the hierarchy reflect the common features of all classes.
• Object classes inherit their attributes and services from one or more super-classes. these may then be specialised as necessary.
• Class hierarchy design can be a difficult process if duplication in different branches is to be avoided.
• Object models and the UML
• The UML is a standard representation devised by the developers of widely used object-oriented analysis and design methods.
• It has become an effective standard for object-oriented modelling.
• Notation
  • Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section;
  • Relationships between object classes (known as associations) are shown as lines linking objects;
  • Inheritance is referred to as generalisation and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy
• Library class hierarchy
• 

• User class hierarchy
•       

• Multiple inheritance
• Rather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classes.
• This can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics.
• Multiple inheritance makes class hierarchy reorganisation more complex
• Multiple inheritance
• 

o       Object aggregation

• An aggregation model shows how classes that are collections are composed of other classes.
• Aggregation models are similar to the part-of relationship in semantic data models.
• Object aggregation
• 

• Object behaviour modelling
• A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case.
• Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects.
• Issue of electronic items
• 

3.9                                 Structured methods

• Structured methods incorporate system modelling as an inherent part of the method.
• Methods define a set of models, a process for deriving these models and rules and guidelines that should apply to the models.
• CASE tools support system modelling as part of a structured method
• Method weaknesses
• They do not model non-functional system requirements.
• They do not usually include information about whether a method is appropriate for a given problem.
• The may produce too much documentation.
• The system models are sometimes too detailed and difficult for users to understand.
• CASE workbenches
• A coherent set of tools that is designed to support related software process activities such as analysis, design or testing.
• Analysis and design workbenches support system modelling during both requirements engineering and system design.
• These workbenches may support a specific design method or may provide support for a creating several different types of system model.
• An analysis and design workbench
• Analysis workbench components
• 

·        Analysis workbench components

• Diagram editors
• Model analysis and checking tools
• Repository and associated query language
• Data dictionary
• Report definition and generation tools
• Forms definition tools
• Import/export translators
• Code generation tools

• Key points
• A model is an abstract system view. Complementary types of model provide different system information.
• Context models show the position of a system in its environment with other systems and processes.
• Data flow models may be used to model the data processing in a system.
• State machine models model the system’s behaviour in response to internal or external events
• Semantic data models describe the logical structure of data which is imported to or exported by the systems.
• Object models describe logical system entities, their classification and aggregation.
• Sequence models show the interactions between actors and the system objects that they use.
• Structured methods provide a framework for developing system models.