Chapter 4: Requirements Engineering (3705)

Chapter 4: Requirements Engineering (3705)

1. Functional and non-functional requirements

   • Functional requirements -> These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations
   • Non-functional requirements -> These are constraints on the services or functions offered by the system
   • requirements are not independent and that one requirement often generates or constrains other requirements
   • they also specify the necessary functionality to ensure that these services/features are delivered effectively.
   • Functional requirements
     • functional requirements specification of a system should be both complete and consistent
   • Non Functional requirements
     • Non-functional requirements are often more critical than individual functional requirements
       • failing to meet a non-functional requirement can mean that the whole system is unusable
     • implementation of these requirements may be spread throughout the system, for two reasons:
       • Non-functional requirements may affect the overall architecture of a system rather than the individual components.
       • An individual non-functional requirement, such as a security requirement, may generate several, related functional requirement
     • Product requirements
     • Organizational requirements
     • External requirements
     • Non-functional requirements such as reliability, safety, and confidentiality requirements are particularly important for critical systems.

2. Requirements engineering processes

   • Requirements engineering is usually presented as the first stage of the software engineering process.
   • three key activities.
     • These are discovering requirements by interacting with stakeholders (elicitation and analysis); converting these requirements into a standard form (specification); and checking that the requirements actually define the system that the customer wants (validation).
   • requirements engineering is an iterative process in which the activities are interleaved.
     • Agile development can be used instead of prototyping so that the requirements and the system implementation are developed together
     • Understand high level requirements and user requirements
     • Understand detailed system requirements and non-functional requirements

3. Requirements elicitation

   • The aims of the requirements elicitation process are to understand the work that stakeholders do and how they might use a new system to help support that work.
   • Eliciting and understanding requirements from system stakeholders is a difficult process for several reasons:
     • Stakeholders often don’t know what they want from a computer system except in the most general terms;
     • Stakeholders in a system naturally express requirements in their own terms and with implicit knowledge of their own work
     • Different stakeholders, with diverse requirements, may express their requirements in different ways
     • Organisational Political factors may influence the requirements of a system
     • The economic and business environment in which the analysis takes place is dynamic
     • process model of the elicitation and analysis process
   • Requirements elicitation techniques
     • There are two fundamental approaches to requirements elicitation:
       • Interviewing, where you talk to people about what they do
         • Interviews may be of two types:
           • Closed interviews, where the stakeholder answers a predefined set of questions
           • Open interviews, in which there is no predefined agenda.
         • Eliciting domain knowledge through interviews can be difficult, for two reasons:
           • All application specialists use jargon specific to their area of work
           • Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain or they think it is so fundamental that it isn’t worth mentioning.
         • To be an effective interviewer, you should bear two things in mind:
           • You should be open-minded, avoid preconceived ideas about the requirements, and willing to listen to stakeholders
           • You should prompt the interviewee to get discussions going by using a springboard question or a requirements proposal
       • Observation or ethnography, where you watch people doing their job to see what artifacts they use
         • Software systems do not exist in isolation.
           • very important that, during the requirements engineering process, you try to understand the social and organizational issues that affect the use of the system.
         • discover implicit system requirements that reflect the actual ways that people work,
         • Ethnography is particularly effective for discovering two types of requirements:
           • Requirements derived from the way in which people actually work, rather than the way in which business process definitions say they ought to work.
           • Requirements derived from cooperation and awareness of other people’s activities - > Relationship between jobs
   • Stories and scenarios
     • Stories are written as narrative text and present a high-level description of system use
     • scenarios are usually structured with specific information collected such as inputs and outputs

4. Requirements specification

   • User requirements are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document.
   • The user requirements for a system should describe the functional and nonfunctional requirements so that they are understandable by system users
   • Ideally, the system requirements should only describe the external behavior of the system and its operational constraints.
   • The level of detail required to completely specify a complex software system, it is neither possible nor desirable to exclude all design information. There are several reasons for this:
     • You may have to design an initial architecture of the system to help structure the requirements specification
     • In most cases, systems must interoperate with existing systems, which constrain the design and impose requirements on the new system.
     • The use of a specific architecture to satisfy non-functional requirements, such as N-version programming to achieve reliability. An external regulator who needs to certify that the system is safe may specify that an architectural design that has already been certified should be used.
   • Natural language specification
     • Invent a standard format and ensure that all requirement definitions adhere to that format.
     • Use language consistently to distinguish between mandatory and desirable requirements.
     • Use text highlighting
     • Do not assume that readers understand technical, software engineering language.
     • Whenever possible, you should try to associate a rationale with each user requirement.
   • Structured specifications
     • Structured language notations use templates to specify system requirements.
     • define one or more standard templates for requirements and represent these templates as structured forms
     • Structured form attributes
   • Use cases
     • Use cases are a way of describing interactions between users and a system using a graphical model and structured text.
   • The software requirements document
     • The software requirements document (sometimes called the software requirements specification or SRS) is an official statement of what the system developers should implement.

5. Requirements validation

   • Requirements validation is the process of checking that requirements define the system that the customer really wants
   • During the requirements validation process, different types of checks should be carried out
     • Validity checks
     • Consistency checks
     • Completeness checks
     • Realism checks
     • Verifiability
   • A number of requirements validation techniques can be used individually or in conjunction with one another:
     • Requirements reviews
     • Prototyping
     • Test-case generation
   • you rarely find all requirements problems during the requirements validation process

6. Requirements change

   • changes to system requirements arise because of changes to the business environment of the system:
     • The business and technical environment of the system always changes after installation
     • The people who pay for a system and the users of that system are rarely the same people.
     • Large systems usually have a diverse stakeholder community, with stakeholders having different requirements.
   • need a formal process for making change proposals and linking these to system requirements.
     • Agile development processes have been designed to cope with requirements that change during the development process
       • change does not go through a formal change management
       • user has to prioritize that change and, if it is high priority, decide what system features that were planned for the next iteration should be dropped
       • better for an independent authority, who can balance the needs of all stakeholders, to decide on the changes that should be accepted.
   • Requirements management planning
     • Requirements management planning is concerned with establishing how a set of evolving requirements will be managed.
       • Requirements identification
       • A change management process
       • Traceability policies
       • Tool support
     • Requires automated support
       • Requirements storage
       • Change management
       • Traceability management
   • Requirements change management
     • should be applied to all proposed changes to a system’s requirements after the requirements document has been approved
       • There are three principal stages to a change management process:
         • Problem analysis and change specification
         • Change analysis and costing
         • Change implementation
     • When changes are made in a rush documents don't get updated. This almost inevitably leads to the requirements specification and the system implementation getting out of step. Once system changes have been made, it is easy to forget to include these changes in the requirements document.

7. The requirements for a system are the descriptions of the services that a system should provide and the constraints on its operation

8. system requirements - > Detailed document about the system requirements

   • System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints.

9. user requirements-> a high level document of the software requirements

   • User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.

10. Can be the same document, depending on the organisations definition of it

Imágenes y archivos del mapa