The document discusses requirements engineering and defines what requirements are. It explains that requirements include functional and non-functional requirements. Functional requirements define what a system should do, while non-functional requirements define properties like usability, performance and reliability. The document also describes the requirements engineering process, which involves gathering, analyzing, documenting and managing requirements.

1. 1

2. 2
 Requirements:
 What the system should do?
 The constraints on its operations
 Requirements:
 It is simple a high level, abstraction statement of a service
that a system should provide and the constraints on that
system.
 Requirements:
 It is the formal definition (in details) of a system function.

3. 3

4. 4
 The requirements are classified into the following three
types:
 Those that should be absolutely met.
 Those that are highly desirable but not necessary.
 Those that are possible but could be eliminated.

5. 5
 On the basis of their functionality, the requirements
are classified into the following two types:
 Functional requirements:
They define factors, such as I/O formats, storage
structure, computational capabilities, timing, and
synchronization.
 Non-functional requirements:
They define the properties or qualities of a product
including usability, efficiency, performance, space,
reliability, portability, etc.

6. 6
 Requirements engineering consists of the following
processes:
 Requirements gathering (elicitation).
 Requirements analysis and modeling.
 Requirements documentation.
 Requirements review.
 Requirements management.

7. 7
 Requirements:
 User 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.
 System Requirements: System requirements are more
detailed descriptions of the software system’s functions,
services, and operational constraints.

8. 8
 User Requirement Definition
The MHC-PMS shall generate monthly
management reports showing the cost of drugs
prescribed by each clinic during that month.

9. 9
 System Requirement
1. On the last working day of each month, a summary of the drugs
prescribed, their cost, and the prescribing clinics shall be generated.
2. The system shall automatically generate the report for printing after
17.30 on the last working day of the month.
3. A report shall be created for each clinic and shall list the individual
drug names, the total number of prescriptions, the number of doses
prescribed, and the total cost of the prescribed drugs.
4. If drugs are available in different dose units (e.g., 10 mg, 20 mg)
separate reports shall be created for each dose unit.
5. Access to all cost reports shall be restricted to authorized users listed on
a management access control list.

10. 10

11. 11
 Requirements gathering and analysis activity by
collecting all information from the customer.
 Then analyzes the collected information to obtain a
clear and thorough understanding of the product to be
developed.

12. 12
 The following basic questions pertaining to the project
should be clearly understood by the analyst in order to
obtain a good grasp of the problem:
1. What is the problem?
2. Why is it important to solve the problem?
3. What are the possible solutions to the problem?
4. What exactly are the data input to the system and what
exactly are the data output by the system?
5. What are the likely complexities that might arise while
solving the problem?
6. If there are external software or hardware with which the
developed software has to interface, then what exactly
would the data interchange formats with the external
system be?

13. 13
 Requirements engineering consists of the following
processes:
 Requirements gathering (elicitation).
 Requirements analysis and modeling.
 Requirements documentation.
 Requirements review.
 Requirements management.

14. 14
 The requirements are gathered from various sources.
 The sources are:
 Customer (Initiator)
 End Users
• Primary Users
• Secondary Users
 Stakeholders
• Role or person with an interest (stake) in the system to
be built.
– Users: Those who use the software
– Customers: Those who pay for the software
– Software developers
– Development Managers

15. 15
 The first portion of this phase, each requirement is
analyzed from the point-of-view of validity, consistency,
and feasibility for firm consideration in the SRS.
 Validity confirms its relevance to goals and objectives.
 Consistently confirms that it does not conflict with other
requirements but supports others where necessary.
 Feasibility ensures that the necessary inputs are available
without bias and error, and technology support is possible
to execute the requirement as a solution.

16. 16
 The second portion of analysis attempts to find for each
requirement, its functionality, features, and facilities
and the need for these under different conditions and
constraints.
 Functionality states “how to achieve the requirement
goal”
 Features describe the attributes of functionality
 Facilities provide its delivery, administration, and
communication to other systems.

17. 17
 SRS document : Software Requirement Specifications
document
 The important parts of SRS document are:
 Functional requirements of the system
 Non-functional requirements of the system, and
 Goals of implementation

18. 18

19. 19

20. 20

21. 21

22. 22

23. 23

24. 24

25. 25

26. 26
 SRS document : Software Requirement Specifications
document
 The important parts of SRS document are:
 Functional requirements of the system
 Non-functional requirements of the system, and
 Goals of implementation

27. 27
 It discusses the functionalities required from the system.
 The high-level functions perform some meaningful piece
of work.
 It define system’s external behavior
 how the system interacts with its environment
 how it responds to inputs
 what output to generate
 and how to behave under certain conditions
 What the system must do and not do

28. 28

29. 29
 Quality attributes or constraints
 Quality Attributes examples: security, performance, and
availability
 Technology constraint: system must be Java-based
 Process constraint: Agile must be used
 It deals with the characteristics of the system which can not
be expressed as functions:
 Maintainability of the system,
 Portability of the system
 Usability of the system
 etc.
 Nonfunctional requirements may include:
 Reliability issues
 Accuracy of results
 Human - computer interface issues
 Constraints on the system implementation, etc.

30. 30
 It documents some general suggestions regarding
development.
 These suggestions guide trade-off among design goals.
 The goals of implementation section might document
issues such as:
 Revisions to the system functionalities that may be
required in the future.
 New devices to be supported in the future
 Reusability issues, etc.

31. 31
 Airline Reservation system:
 Functional
• “a user can search for a flight. If a flight is selected, the user
has 2 minutes to confirm booking or the flight will be
released”
• How the system will interact and respond to use?
 Non-Functional
• “the response time for a search transaction under peek load
of 10,000 users must not exceed 2s”
• “the throughput of the system is 100 search transactions per
second”
• What are the quality attributes of the system?

32. 32
 Customers almost never give quantitative non-functional
requirements
 Instead of:
• “the response time for a search transaction under peak load
of 10,000 users must not exceed 2s”
• Customers will say: “the system should be fast when number
of users is high”
 Instead of:
• “the throughput of the system is 100 search transactions per
second”
• Customers will say: “the system must accept high number of
search commands”
 Requirements such as “I want a secure system” and “I
want a system that is easy to use” will surface all the
time

33. 33
 The functional requirements is identified from:
 Informal problem description document
 A conceptual understanding of the problem.
 The functional requirements is identified by identifying
the different types of users who might use the system
and then try to identify the requirements from each
user’s perspective.

34. 34
 Example: Consider the case of the library system, where
 F1: Search Book function
 Input: an author’s name
 Output: details of the author’s books and the location of
these books in the library

35. 35
 A function can be specified by
1) Identifying the state at which the data is to be input to
the system.
2) The input data domain.
3) The output data domain
4) The type of processing to be carried on the input data to
obtain the output data.

36. 36
 Example: - Withdraw Cash from ATM (Automatic Teller
Machine)
 R1: withdraw cash
• Description: The withdraw cash function first determines
the type of account that the user has and the account
number from which the user wishes to withdraw cash. It
checks the balance to determine whether the requested
amount is available in the account. If enough balance is
available, it outputs the required cash, otherwise it
generates an error message.

37. 37
 R1.1 select withdraw amount option
• Input: “withdraw amount” option
• Output: user prompted to enter the account type
 R1.2: select account type
• Input: user option (Checking or Saving)
• Output: prompt to enter amount
 R1.3: get required amount
• Input: amount to be withdrawn in integer values greater than
100 and less than 10,000 in multiples of 100.
• Output: The requested cash and printed transaction
statement.
 Processing: the amount is debited from the user’s account if
sufficient balance is available, otherwise an error message
displayed.

38. 38
 It deals with the characteristics of the system which
can not be expressed as functions:
 Maintainability of the system
 Portability of the system
 Usability of the system
 Reliability issues
 Performance issues
 Human - computer interface issues
 Interface with other external systems
 Security and maintainability of the system
 etc.

39. 39

40. 40

41. 41
 How to quantify non-functional requirements to read:
 “10,000 users peak load”
 “2s response time”
 “100 Tx per second throughput”
 “user must learn how to perform a search in operation
after 3 attempts”
 Requirements Engineering process transforms vague non-
functional requirements into more quantitative form
 Non quantitative requirements are difficult to design
and implement

42. 42
1. Concise. (‫موجز‬)
2. Structured. (‫منظم‬)
3. Black-box view.
4. Conceptual integrity. (‫المفاهيم‬‫كاملة‬)
5. Response to undesired events. (‫االستجابة‬‫لالحداث‬‫الغير‬‫مرغوب‬
‫فيها‬)
6. Verifiable. (‫يمكن‬‫التحقق‬‫منه‬)

43. 43
 Without developing the SRS document, the system would
not be implemented according to customer needs.
 Software developers would not know whether what they
are developing is what exactly required by the
customer.
 Without SRS document, it will be very much difficult for
the maintenance engineers to understand the
functionality of the system.
 It will be very much difficult for user document writers
to write the users’ manuals properly without
understanding the SRS document.

44. 44
 A decision tree gives a graphic view of the processing
logic involved in decision making and the corresponding
actions taken.
 The edges of a decision tree represent conditions
 The leaf nodes represent the actions to be performed
depending on the outcome of testing the condition.

45. 45
 Consider Library Membership Automation Software
(LMS) where it should support the following three
options:
 New member
 Renewal
 Cancel membership

46. 46
1. New member option:
 Decision: When the 'new member' option is selected, the
software asks details about the member like the member's
name, address, phone number etc.
 Action: If proper information is entered then a
membership record for the member is created and a bill is
printed for the annual membership charge plus the
security deposit payable.

47. 47
2. Renewal option:
 Decision: If the 'renewal' option is chosen, the LMS asks
for the member's name and his membership number to
check whether he is a valid member or not.
 Action: If the membership is valid then membership expiry
date is updated and the annual membership bill is printed,
otherwise an error message is displayed.

48. 48
3. Cancel membership option:
 Decision: If the 'cancel membership' option is selected,
then the software asks for member's name and his
membership number.
 Action: The membership is cancelled, a cheque for the
balance amount due to the member is printed and finally
the membership record is deleted from the database.

49. 49

50. 50
 A decision table is used to represent the complex
processing logic in a tabular or a matrix form.
 The upper rows of the table specify the variables or
conditions to be evaluated.
 The lower rows of the table specify the actions to be
taken when the corresponding conditions are satisfied.
 A column in a table is called a rule.
 A rule implies that if a condition is true, then the
corresponding action is to be executed.

51. 51

52. 52