Lecture_3._Requirements_Analysis_Best_Practices[1]

1.

Requirements Analysis Best Practices
Lecture 3
GLOBAL TALENT | SEAMLESS COLLABORATION | MEASURABLE
IMPACT
coherentsolutions.com

2.

3.

The cost of correcting the error
The cost of correcting the error, depending on the stage of development, is as
follows:
•Requirements - x1
•Design - x5
•Development - x15
•Testing - x25
•Production - x100+

4.

• Requirements are not sole
responsibility of Product Owners and
BAs;
• good requirements are always a result
of mutual effort of all team members
• The earlier we study requirements
carefully, fill in all the gaps and
eliminate all conflicts and ambiguities,
the better;
• the later it happens, the higher the
cost to fix the issue

5.

Why is it important to test the requirements
DETERMINE: WHAT AND
UNDER WHAT
CONDITIONS
IT’S A BASIS
THE SYSTEM SHOULD DO​
PROJECT PLAN
TO CREATE
SIMPLIFY PRIORITIZATION IN A
SET OF TASKS (AS
REQUIREMENTS RANKED FOR
IMPORTANCE, STABILITY,
PRIORITY)
HELP PREVENT OR
RESOLVE CONFLICT
SITUATIONS​
ALLOW TO OBJECTIVELY
ASSESS THE DEGREE OF
PROGRESS IN THE
DEVELOPMENT OF THE
PROJECT

6.

Requirement classification by level

7.

Requirement levels
Business requirements –
business statements of the goals, objectives, or needs ​
which should help the organization to maximize profit, ​
minimize expenditures, raise service to a new level

8.

Requirement levels
User Requirements – are general statements of user goals or
business tasks that users need to perform.​
Describe the tasks that the user can perform using the
system being developed (system response to user actions,
scenarios)

9.

Requirement levels
Software Requirements –​ describes in detail all the
functions and under what conditions the application
should perform
Requirements convey the expectations of users from
the software product

10. Requirement classification by type

• FUNCTIONAL
• Describe what system should do
at high-level: USER requirements
in detail, will all exceptions:
SYSTEM requirements
• represented or stated in the form
of input to the system, the
operation performed and the
output expected
• NON-FUNCTIONAL
• Quality constraints that the
system must satisfy, e.g.
Portability
Security
Maintainability
Reliability
Scalability
Performance
Reusability
Flexibility

11.

Functional requirements (Example)
Let’s imagine we’re developing a messaging app
The functional requirements, in this case, would be:
1.The app must be able to send messages
2.Should be possible to delete sent message

12.

13.

Non-Functional requirements (Example)
Non-functional requirements might be as follows:
1.The service must offer full functionality in all major browsers: Microsoft Edge, Google
Chrome (latest two versions), Mozilla Firefox (latest two versions), Opera, Safari (latest
version).
2.Mobile layouts must be supported

14.

What 'good' requirements should be
Complete
• All services should be defined
Consistent
• Requirements should not have
contradictions
Specific, measurable
Verifiable, testable

15.

16. Widespread issues with requirements

• Ambiguity (requirements can be
interpreted differently by users, customers,
and developers)
• Incompleteness, lack of detail and
precision
• Conflicts between requirements

17.

Life in a world of imperfect requirements
Map
Map the terrain
•Who is in charge of requirements? Who are decision
makers for different types of requirements? Who is
responsible for documenting requirements? How to contact
them? Where to find the specs? Do I have access?
Study
Study available information carefully
Make
Make a list of questions
Suggest
Suggest solutions
•Do not be shy to suggest solutions: it is often appreciated
•Do not forget to confirm the solutions with
leads/stakeholders
Make
Make sure the responses are clear, answer the questions,
are documented
•Answers often generate new questions: be prepared!

18.

Life in a world of imperfect requirements
Be
proactive
Be
curious
Be
attentive

19.

Questions?