1
Functional Requirements
2
Functional Requirements - 1
• Statements describing what the system
does
• Functionality of the system
3
Functional Requirements - 2
• Statements of services the system
should provide
– Reaction to particular inputs
– Behavior in particular situations
4
Functional Requirements - 3
• Sequencing and parallelism are also
captured by functional requirements
• Abnormal behavior is also documented
as functional requirements in the form
of exception handling
5
Functional Requirements - 4
• Functional requirements should be
complete and consistent
• Customers and developers usually
focus all their attention on functional
requirements
6
Functional Requirements Example # 1
• The system shall solve a quadratic
equation using the following formula
x = (-b+sqrt(b2
– 4*a*c))/2*a
7
Functional Requirements Example # 2
• The user shall be able to search either
the entire database of patients or select
a subset from it (admitted patients, or
patients with asthma, etc.)
8
Functional Requirements Example # 3
• The system shall provide appropriate
viewers for the user to read documents
in the document store
9
Functional Requirements Example # 4
• Every order shall be allocated a unique
identifier (ORDER_ID) which the user
shall use to access that order
10
Comments on Examples
• Notice the level of detail in different
requirements described above. Some
are very detailed compared to others
11
Comments on Examples
• Notice the ambiguity in the
requirement, which uses the term
‘appropriate viewers’
• This requirement does not mention the
formats of documents and types of
viewers, which can be used
12
Comments on Examples
• Notice the ambiguity in the
requirement for solving the quadratic
equation. The requirement does not
speak about the possibility when the
value of ‘a’ is zero
x = (-b+sqrt(b2
– 4*a*c))/2*a
13
Comments on Examples
• Incomplete and ambiguous
requirements are open to multiple
interpretations and assumptions
• This can lead to the development of
poor quality, or faulty, software
products

Functional-Requirements in Software Requirement Engineering

  • 1.
  • 2.
    2 Functional Requirements -1 • Statements describing what the system does • Functionality of the system
  • 3.
    3 Functional Requirements -2 • Statements of services the system should provide – Reaction to particular inputs – Behavior in particular situations
  • 4.
    4 Functional Requirements -3 • Sequencing and parallelism are also captured by functional requirements • Abnormal behavior is also documented as functional requirements in the form of exception handling
  • 5.
    5 Functional Requirements -4 • Functional requirements should be complete and consistent • Customers and developers usually focus all their attention on functional requirements
  • 6.
    6 Functional Requirements Example# 1 • The system shall solve a quadratic equation using the following formula x = (-b+sqrt(b2 – 4*a*c))/2*a
  • 7.
    7 Functional Requirements Example# 2 • The user shall be able to search either the entire database of patients or select a subset from it (admitted patients, or patients with asthma, etc.)
  • 8.
    8 Functional Requirements Example# 3 • The system shall provide appropriate viewers for the user to read documents in the document store
  • 9.
    9 Functional Requirements Example# 4 • Every order shall be allocated a unique identifier (ORDER_ID) which the user shall use to access that order
  • 10.
    10 Comments on Examples •Notice the level of detail in different requirements described above. Some are very detailed compared to others
  • 11.
    11 Comments on Examples •Notice the ambiguity in the requirement, which uses the term ‘appropriate viewers’ • This requirement does not mention the formats of documents and types of viewers, which can be used
  • 12.
    12 Comments on Examples •Notice the ambiguity in the requirement for solving the quadratic equation. The requirement does not speak about the possibility when the value of ‘a’ is zero x = (-b+sqrt(b2 – 4*a*c))/2*a
  • 13.
    13 Comments on Examples •Incomplete and ambiguous requirements are open to multiple interpretations and assumptions • This can lead to the development of poor quality, or faulty, software products

Editor's Notes

  • #2 As the name suggests that FRs are the statements describing what the system does? In other words these capture the functionality of the system, so they are the fundamental part of SRs. FR are the backbone of SRs. It depends on complexity of Software that how many FRs should be in document. FRs are the core on the basis of which software product is built.
  • #3 FRs are the statements of service the system should provide into clearly describe external behavior Both of these visible external behavior should be capture in Functional Requirements. FRs capture: The Core of s/w product Reaction to particular Input And Behavior in particular situation
  • #4 Depending on the domain for which user are developing software for example if you are working for concurrent and real time system the sequencing and parallelism aspects of the domain. Another important part of FR is capturing exception handling in certain situation. In almost every case the abnormal behavior is captured. FR must include exception handling
  • #5 It is difficult to document reqs completely and consistently. (because info is coming from multiple sources/stakeholders----In some cases Reqs in thousands of number) so it is challenge for Req Engg to document requirements completely in complex systems.
  • #6 It is very simple and very detailed requirement as the formula is simple there is no complications. It gives detailed formula to calculate. But what it does not mention is the possibility when the value of variable is zero what the system will do in case the value of variable a is zero. Computer will give you divide by zero error. That is not the desired functionality of system. The system should degrade gracefully. But how it will degrade. So there is also Ambiguity. It is up to the developer to think about the graceful degradation……there is two options that software simply refuses to solve the equation and say this is an error and user expected to give proper input. Other is that the product should asked the user that whether he/she wants a solution in linear equation.
  • #8 This requirement is described at much higher level as compare to the two requirements discussed before.