This document discusses requirements engineering and analysis. It uses the analogy of blind men feeling different parts of an elephant to represent the various perspectives in requirements analysis, including process, system, functions, and reports. It outlines techniques for requirements analysis like activity diagrams, flowcharts, use cases, and the "Method H" template. The document stresses the importance of effective communication of requirements through documentation, reviews, and revision strategies.

1. Requirements
Engineering
Mohamed Shaaban| Systems Analyst
February 2011| mohamed.shaaban@mail.link.net
w w w. l i n kd e v. c o m
w w w. l i n kd e v. c o m

2. Blind Men
and the
Elephant
w w w. l i n kd e v. c o m

3. The blind man
who feels a leg
says the elephant
is like a pillar
w w w. l i n kd e v. c o m

4. the one who feels
the tail says the
elephant is like
a rope
w w w. l i n kd e v. c o m

5. the one who feels
the trunk says the
elephant is like a
tree branch
w w w. l i n kd e v. c o m

6. the one who feels
the ear says the
elephant is like a
hand fan
w w w. l i n kd e v. c o m

7. the one who feels
the belly says the
elephant is like a
wall
w w w. l i n kd e v. c o m

8. and the one who
feels the tusk
says the elephant
is like a solid pipe
w w w. l i n kd e v. c o m

9. The king explained to them:
"All of you are right. The reason why every one of you
is telling it differently is because each one of you
touched the different part of the elephant. So,
actually the elephant has all the features you
mentioned."
w w w. l i n kd e v. c o m

10. III. Requirements Analysis
• The system is your elephant, and it has
multiple views:
– Process Analysis
– System Analysis
– Functions Analysis
– Reports Analysis
w w w. l i n kd e v. c o m

11. Process Analysis
• Swimlane Activity Diagrams
– Depict the flow of activities
– A lane is assigned to each actor
– Data is not present
– Allows you to pinpoint problems
– Can be used to compare existing models with
proposed models
w w w. l i n kd e v. c o m

12. Process Analysis
– Swimlane example
w w w. l i n kd e v. c o m

13. Process Analysis
• Flowcharts
– Decide on the level of abstraction you want to
include
– More user friendly
– Less focus on actors
– Better view of routing decisions
w w w. l i n kd e v. c o m

14. Process Analysis
– Flowcharts example
w w w. l i n kd e v. c o m

15. System Analysis
• System Leveling for Scoping
System Name
Major Module 1 Major Module 2 Major Module 3
Task 1
Function 1
Task 2
Function 2 Task 3
w w w. l i n kd e v. c o m

16. System Analysis
• User Stories
– Agile concept
– Define user roles and goals
• As a book buyer, I want to browse books
• As a system admin, I want to cancel a transaction
– Find out the details of each story
• What is the result of the action, from a business perspective? e.g.
after payment, do shipping?
• What is the result of the action, from a system perspective? e.g.
after saving request, notify user? Keep data?
– Find the links between stories
• Will order cancellation affect payment? Shipping?
– A good story is singular, estimable, and testable
w w w. l i n kd e v. c o m

17. System Analysis
• Use Cases
– Scenario description: the user interaction with the
system
– Easier to envision and customer-friendly
– Summarized enough to produce test cases
– They lack the integration aspect
– They say very little of the data
– They deal poorly with quality requirements
w w w. l i n kd e v. c o m

18. System Analysis
– Use Cases example
Usecase ID UC-CusAcc-1
Description This usecase scenario describes the steps of creating a new customer profile
on the system
Actors Sales agent
Assumptions & None
Constraints
Pre-Conditions  The sales agent has an active user account and logged in to the system
Basic Flow 1. The sales agent chooses to create a new customer profile
2. The system displays the New Customer Profile form (see Data Form 1)
3. The sales agent fills in the form fields and submits it
4. The system checks uniqueness of customer data against existing
accounts. Please refer to Uniqueness Check for more information
5. For new customers, the system saves their information and requests a
unique identifier (UCID) from the CRM system
6. The system displays a message that confirms creation of the profile to
the agent. The message includes the UCID
Alternative Flows  In step #5, in case the CRM system is down, the system (Offline Sales
Portal) should generate a UCID for the new profile, as well as enable the
agent to enter a UCID manually into the form. The UCID provided by the
agent should w .validateddfor uniqueness against the system database
w w be l i n k e v . c o m
Post Conditions  A new customer profile is created to which new sales can be linked
Notes Please refer to Figure 3.1

19. Functions Analysis
• The following attributes generate the requirement
– Who: who will do an action, and who will receive it or be affected by it
– Why: the real need, the problem that the requirement will solve
– What: the business activity. There are 3 “whats”:
• What does the user do (as-is)
• What does he want (the real problem)
• What does he ask for (to-be)
– Where: the environment in which the work takes place, and the scope
of implementation across geographical areas and branches
– When: timing, not only of delivery but also of the inclusion in the
process
– How: the implementation, how will the problem be solved (design)
w w w. l i n kd e v. c o m

20. Functions Analysis
• Method H
Functionality
What do you do?
Inputs Outputs
Business Rules What do you give
What do other
What rules apply? to other people?
people give you?
Data
What do you need
to keep track of?
w w w. l i n kd e v. c o m

21. Functions Analysis
– Method H example: employee monthly payment
Functionality
•Take out deductions
•Take out taxes/loans
•Print check
•Post to GL
Inputs Business Rules Outputs
•Hours worked •Check with manager before •Check
•Managers approval calculation •Payments record
•Don’t calculate if employee
is fired
Data
•Employee records
•Deduction tables
•Taxes table
w w w. l i n kd e v. c o m

22. Reports Analysis
• Think about the following
– Description: why do users need this report?
– Distribution method: will the report be printed? Will it
be automatically generated and emailed to customers?
– Specific output formats: PDF, Excel… etc
– Report usage frequency: daily, monthly, yearly?
– Filtering of data
– Sorting of rows and order of columns
– Grouping rules: by department, then employees title?
– Formulas: subtotals, grand totals, average… etc
w w w. l i n kd e v. c o m

23. IV Requirements Communication
• Possible Analyst Deliverables
– Stakeholders List
– Requirements Specifications Document
– Change Requests
– Prototype
• Horizontal: shallow view of the system with no logic
• Vertical: deep slice of the system
• Throw-away Prototype: in the form of paper and pen
• Evolutionary Prototype: like HTML, extended later to produce the actual
application
– Internal
• Requirements Database
• Traceability Matrices
• Requirements Management Plan
w w w. l i n kd e v. c o m

24. IV Requirements Communication
• Recommended Documentation Practices
Keyword Meaning
MUST, SHALL Absolute requirement of the specification
MUST NOT, SHALL NOT Absolute prohibition of the specification
SHOULD, RECOMMENDED Requirement can be ignored if there’s a valid reason, but
the implication must be understood and communicated
before choosing a different approach
SHOULD NOT, NOT A particular item may be acceptable in certain situations,
RECOMMENDED but the implication must be understood and
communicated before implementing it
MAY, OPTIONAL A requirement is optional
w w w. l i n kd e v. c o m

25. IV Requirements Communication
– Naming Consistency: make sure you use the same
terminology with one definition
– Separate facts from assumptions and goals from
requirements
– Writing for an audience
• Sophisticated vs. Simple, average users
– Introductory section
• Always write an introduction to orient readers
• Include document purpose, audience, and scope
• Refer to relevant documents
• Introduce the product
w w w. l i n kd e v. c o m

26. IV Requirements Communication
• Types of Revision
– Peer Review: Help you see weak points without the
pressure of a supervisor judgment
– Technical Review
• Developers
• Quality Control
• Quality Assurance
– External/Customer Review
• Agreement on Requirements and Signoff
w w w. l i n kd e v. c o m

27. IV Requirements Communication
• Revision Strategy
– Check the flow of ideas
– Validate the accuracy of information
– Review pictures: location and caption
– Check clarity and consistency
– Proofread: check grammar, spelling, and punctuation
– Confirm accuracy of the Table of
Content, References, and Index
w w w. l i n kd e v. c o m

28. Thank You
w w w. l i n kd e v. c o m