Requirement Engineering (Exam Notes)

1. Functional Requirement
- description of the service that the software must offer
- describes a software system or its component
- A function is nothing but inputs to the software system, its behaviour and outputs
- It can be a calculation, data manipulation, business process, user interaction, or
any other specific functionality which defines what function a system is likely to
perform

2. Functional Requirement example

- The software automatically validates customers against the ABC Contact
Management System
- The Sales system should allow users to record customers sales
- The background colour for all windows in the application will be blue and have a
hexadecimal RGB colour value of 0x0000FF
- Only Managerial level employees have the right to view revenue data
- The software system should be integrated with banking API
- The software system should pass Section 508 accessibility requirement

3. Benefits of functional-requirement
- Helps to check whether the application is providing all the functionalities that
were mentioned in the functional requirement of that application
- A functional requirement document helps to define the functionality of a system
or one of its subsystems
- Functional requirements along with requirement analysis help identify missing
requirements. They help clearly define the expected system service and behaviour
- Errors caught in the Functional requirement gathering stage are the cheapest to fix
- Support user goals, tasks, or activities

4. Functional requirement types

- Transaction Handling
- Business Rules
- Certification Requirements
- Reporting Requirements
- Administrative functions
- Authorization levels
- Audit Tracking
- External Interfaces
- Historical Data management
- Legal and Regulatory Requirements
5. Why Requirement Engineering is important?
- Published surveys showed that many systems failed because their requirements
had not been accurately identified and analysed
- Mid-1980s RE became recognized as sub-discipline
- requirements engineering can greatly reduce the amount of rework needed later in
the life of the software product and can improve various qualities of the software
cost effectively
- RE determines how efficiently and rapidly products can be generated and this is
particularly important in a global competitive market where the ‘time to market’
and meeting stakeholder requirements are the key success factors

6. Benefits of Requirement Engineering

- Fewer requirements defects
- Reduced development rework
- Fewer unnecessary features
- Lower enhancement costs
- Faster development
- Fewer miscommunications
- Reduced scope creep
- Reduced project chaos
- More accurate system-testing estimates
- Higher customer and team member satisfaction

7. Is Requirement Engineering difficult?

- It is hard to elicit human needs and purposes, and to bring them into harmony
- handling to a formally programmed machine degree of control over a complex and
non-formal reality
- Too often systems engineers forgo sufficient RE activity
 They do not understand how to do RE properly
 Rush to start coding

8. General problem with Requirement Engineering

- Lack of expertise
- Initial ideas are often incomplete, wildly optimistic, and firmly entrenched in the
minds of the people leading the acquisition process
- Difficulty of using complex tools and diverse methods associated with
requirements gathering may negate the anticipated benefits of a complete and
detailed approach
9. 5 Reasons why you struggle with Requirements?
- Most business grossly underestimate the time and effort needed
- Employees don’t have the skills to write effective requirements documents
- insufficient involvement from stakeholders
- whole-brained thinking is needed to develop complete requirements
- Paperwork is a pain and time is your most valuable resource

10. What is Requirement?

- expression of desired behaviour, and a software capability needed by the user to
solve a problem to achieve an objective

11. Requirement elicitations

- Also known as requirement gathering
-

12. Requirement Analysis and Modelling

- process of studying and analysing the needs of stakeholders (e.g., customer, user)
in view of coming up with a “solution”
- The main purpose of the requirements analysis activity is to analyse the gathered
requirements to remove all ambiguities, incompleteness, and inconsistencies from
the gathered customer requirements and to obtain a clear understanding of the
software to be developed
- Once the requirements are gathered, we document the requirements in
a Software Requirements Specification (SRS) document, use cases or as User
Stories, which are shared with the stakeholders for approval. This document
is easy to understand for both normal users and developers

13. Why change in requirements for software systems are inevitable?

- Software change is inevitable. The evolution of new technologies and applications
are increasing today. To improve the performance of a system, new software and
applications must be used. As a result, changes are required for the existing model
of the system
- The system requirements must be changed as per the user requirements. If the user
wants a more efficient system, then the requirements of the existing system must
be analysed and need to predict the changes. Then rework must be done to the
system as per the predicted changes

14. Requirement Elicitation Steps:

1. Elicitation
 Where the requirements are first gathered. To elicit accurate requirements,
the analyst must ask the right kind of questions and then listen carefully to
the answers. There are a number of techniques for eliciting requirements
 and your project may need to use multiple techniques depending on the
circumstances
 includes interviews, facilitated sessions, prototypes, questionnaires and
more
2. Analysis
3. Specification
 During this step, the analyst prioritizes and formally documents the
requirements in a Requirements Definition Report. The requirements are
also numbered in a way that allows them to be tracked through the rest of
the lifecycle. Finally, they are checked to make sure that they can
ultimately be tested
4. Validation
 Where the “analysing” starts. The purpose of validation is to make certain
that the information conveyed during elicitation accurately represents the
needs and expectations of the clients and stakeholders. The work here
includes consolidating requirements, rationalizing them, looking got
overlaps and gaps and creating models to help visualize processes
5. Software Requirement Specifications (SRS)
 A document that describes what the software will do and how it will be
expected to perform. It also describes the functionality the product needs
to fulfil all stakeholders (business, users) needs

15. Requirement Elicitations Techniques

- Artefact-Driven Elicitations Techniques
 Background study
 Data collection, questionnaires
 Scenarios, storyboards for problem world exploration
 Prototypes, mock-ups for early feedback
 Knowledge reuse: domain-independent, domain-specific
- Stakeholder-Driven Elicitation Techniques
 Interviews
 Observation and ethnographic studies
 Group sessions

16. Characteristics of requirements set as a whole

a. Complete
b. Consistent
c. Modifiable
d. Traceable
17. Activities for Requirement Analysis. 4 types activity:
- Eliciting requirements: the task of communicating with customers and users to
determine what their requirements are. This is sometimes also called requirements
gathering.
- Analysing requirements: determining whether the stated requirements are
unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
- Requirements modelling: Requirements might be documented in various forms,
such as natural-language documents, use cases, user stories, or process
specifications.
- Review and retrospective: Team members reflect on what happened in the
iteration and identifies actions for improvement going forward.

18. Main activities involve in requirement analysis

- Identify customer's needs.
- Evaluate system for feasibility.
- Perform economic and technical analysis.
- Allocate functions to system elements.
- Establish schedule and constraints.
- Create system definitions.

19. Requirement Modelling

- scenario-based modelling
- data modelling
- flow-oriented modelling
- class-based modelling
- behavioural modelling

20. The requirements for Requirements Document

- Specify external system behaviour
- Specify implementation constraints
- Easy to change
- Serve as reference tool for maintenance
- Record forethought about the life cycle of the system i.e. predict changes
- Characterise responses to unexpected events
21. Characteristics of excellent requirements statements
- Complete
- Correct
- Feasible
- Necessary
- Prioritized
- Unambiguous
- Verifiable