Requirment engineering

Question 1

What are the steps in the requirement engineering?

Answer 1

–1) Understand the problem
•use data gathering techniques to elicit requirements
•Eg. Interviews, Questionnaires, Focus Groups, Prototyping, Observation,…
–2) Model and Analyze the problem
•use some modeling method(s)
•Eg. Structured Analysis, Object Oriented Analysis, Formal Analysis,…
–3) Attain agreement on the nature of the problem
•validation
•conflict resolution, negotiation
–4) Communicate the problem
•specifications, documentation, review meetings,
–5) Manage change as the problem evolves
•Requirements continue to evolve throughout software development
•(introducing new software changes the problem!!!)
•requirements management -maintain the agreement

Question 2

What is a requirement?

Answer 2

•A requirement is a statement of one of the following:
–1. Whata system must do
–2. A known limitationor constrainton resources or design
–3. How well the system must do what it does
•The first definition is for Functional Requirements
•The second and third definitions are for Non-Functional Requirements (NFRs)

Question 3

What is requirement engineering?

Answer 3

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

Question 4

What is software management?

Answer 4

A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirement of the system.

Question 5

What are functional requirements?

Answer 5

Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

Question 6

What are non-functional requirements?

Answer 6

constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

Question 7

What are domain requirements?

Answer 7

Requirements that come from the application domain of the system and that reflect characteristics of that domain.

Question 8

What requirements should be?

Answer 8

•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.

Question 9

What are different classifications of non-functional requirements?

Answer 9

•Product requirements
–Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
•Organisational requirements
–Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.
•External requirements
–Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Question 10

What are some domain requirements problems?

Answer 10

•Understandability
–Requirements are expressed in the language of the application domain;
–This is often not understood by software engineers developing the system.
•Implicitness
–Domain specialists understand the area so well that they do not think of making the domain requirements explicit.

Question 11

What are the steps in the requirement engineering process?

Answer 11

•Inception—ask a set of questions that establish …
–basic understanding of the problem
–the people who want a solution
–the nature of the solution that is desired, and
–the effectiveness of preliminary communication and collaboration between the customer and the developer
•Elicitation—elicit requirements from all stakeholders
•Elaboration—create an analysis model that identifies data, function and behavioral requirements
•Negotiation—agree on a deliverable system that is realistic for developers and customers
•Specification—can be any one (or more) of the following:
–A written document
–A set of models
–A formal mathematical
–A collection of user scenarios (use-cases)
–A prototype
•Validation—a review mechanism that looks for
–errors in content or interpretation
–areas where clarification may be required
–missing information
–inconsistencies (a major problem when large products or systems are engineered)
–conflicting or unrealistic (unachievable) requirements.
•Requirements management

Question 12

What is requirement elicitation?

Answer 12

•Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.
•Stages include:
–Requirements discovery,
–Requirements classification and organization,
–Requirements prioritization and negotiation,
–Requirements specification.

Question 13

What are some problems with requirement elicitation?

Answer 13

• 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 may change.

Question 14

What are some requirement elicitation techniques?

Answer 14

•➜Traditional Approaches
–Introspection
–Interview/survey
–Group elicitation
•➜Observational approaches
–Protocol analysis
–Participant Observation (ethnomethodology)
•➜Model-based approaches
–Goal-based: hierarchies of stakeholders’ goals
–Scenarios: characterizations of the ways in which the system is used
–Use Cases: specific instances of interaction with the system
•➜Exploratory approaches
–Prototyping (“plan to throw one away”)

Question 15

What is requirement analysis?

Answer 15

• A requirement is a feature (ability) of the system that client requires
• Requirements analysis seeks to assess (analyze) and specify the behavior of the final system as a set of requirements.
• Requirements analysis results in a complete, consistent, correct, and unambiguousspecification of the requirements
• Requirements analysis can be iteratively carried out or done in a top-down fashion

Question 16

What does it mean for the requirement to be complete?

Answer 16

All features of interest to the client are described by the requirements

Question 17

What does it mean for the requirement to be consistent?

Answer 17

No requirement contradicts any other requirement in the specification

Question 18

What does it mean for the requirement to be unambiguous?

Answer 18

The requirements cannot be interpreted in multiple ways.

Question 19

What does it mean for the requirement to be correct?

Answer 19

The requirements describe all features of interest to the client, but not extra or superfluous features

Question 20

What is the purpose of requirement analysis?

Answer 20

•Tool used by software developers to understand
–The functions of the application to be developed
–What the client/user expects the application to do
–The importance of each function to the client/user
–Necessary details of the application domain
Tool also helps the clients/users to understand
–What their own requirements are
–The feasibility and costs of some features that may be difficult to implement (this may change the user’s prioritization of features)

Question 21

When are requirements useful?

Answer 21

Requirements are only usefulif they have the following properties
–Realism: system can be implemented without violating any constraints
–Verifiability: As the system is designed and built repeatable tests can be developed that demonstrate the system fulfills each requirement
–Traceability: Each requirement can be mapped to one or more system functions, each system function can be mapped to at least one requirement. Interdependence between requirements is also mapped

Question 22

What is a feasibility study?

Answer 22

•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.

Question 23

What is requirement specification?

Answer 23

•The process of writing donwthe user and system requirements in a requirements document.
•User requirements have to be understandable by end-users and customers who do not have a technical background.
•System requirements are more detailed requirements and may include more technical information.
•The requirements may be part of a contract for the system development
–It is therefore important that these are as complete as possible.

Question 24

What is structured specification?

Answer 24

• An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way.
• This works well for some types of requirements e.g. requirements for embedded control system but is sometimes too rigid for writing business system requirements.

Question 25

What is a form-based specification?

Answer 25

• Definition of the function or entity.
• Description of inputs and where they come from.
• Description of outputs and where they go to.
• Information about the information needed for the computation and other entities used.
• Description of the action to be taken.
• Pre and post conditions (if appropriate).
• The side effects (if any) of the function.

Question 26

What is tabular specification?

Answer 26

• Used to supplement natural language.
• Particularly useful when you have to define a number of possible alternative courses of action.
• For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios.

Question 27

What are use cases?

Answer 27

• Use-cases are a kind of scenario that are included in the UML.
• Use cases 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.
• High-level graphical model supplemented by more detailed tabular description (see Chapter 5).
• UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

Question 28

Which dimensions are used to verify requirements?

Answer 28

• 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?

Question 29

What are some requirement validation techniques?

Answer 29

•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.

Question 30

What does the requirement review check?

Answer 30

• 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?

Question 31

What is requirement management?

Answer 31

•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.

Question 32

What are principal activities in the requirement change management?

Answer 32

–Problem analysis. Discuss requirements problem and propose change;
–Change analysis and costing. Assess effects of change on other requirements;
–Change implementation. Modify requirements document and other documents to reflect change.

Question 33

What are some requirement management decisions?

Answer 33

–Requirements identificationEach requirement must be uniquely identified so that it can be cross-referenced with other requirements.
–A change management process This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section.
–Traceability policies these policies define the relationships between each requirement and between the requirements and the system design that should be recorded.
–Tool support tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.

Question 34

What are enduring requirements?

Answer 34

Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models

Question 35

What are volatile requirements?

Answer 35

Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy