2. 2
INTRODUCTION
• Requirements form the basis for all software products
• Requirements engineering is the process, which enables us to determine
the requirements for a software product systematically
4. 4
REQUIREMENT
• Something required, something wanted or needed
• Webster’s dictionary
• There is a huge difference between wanted and needed and it should be
kept in mind all the time
6. 6
SOFTWARE REQUIREMENTS - 1
• A complete description of what the software system will do without
describing how it will do the software requirements represent it.
7. 7
SOFTWARE REQUIREMENTS - 2
• Software requirements are complete specification of the desired external
behavior of the software system to be built
• They also represent External behavior of the system
9. 9
SOFTWARE REQUIREMENTS - 4
Software requirements may be:
• May be the basis for the contract itself – therefore must be
defined in detail;
• Part of the technical document, which describes a product
10. REQUIREMENTS ABSTRACTION
“If a company wishes to let a contract for a large software development
project, it must define its needs in a sufficiently abstract way that a solution is
not pre-defined.The requirements must be written so that several
contractors can bid for the contract, offering, perhaps, different ways of
meeting the client organization’s needs. Once a contract has been awarded,
the contractor must write a system definition for the client in more detail so
that the client understands and can validate what the software will do. Both of
these documents may be called the requirements document for the system.”
10
11. 11
IEEE DEFINITION
• A condition or capability that must be met or possessed by a system...to satisfy a
contract, standard, specification, or other formally imposed document
• IEEE Std 729
12. 12
SOURCES OF REQUIREMENTS
• Stakeholders
• People affected in some way by the system
• Documents
• Existing system
• Domain/business area
13. 13
LEVELS OF SOFTWARE REQUIREMENTS
• Stakeholders describe requirements at different levels of detail
• “What versus How”
• “One person’s floor is another person’s ceiling”
14. 14
WHATVERSUS HOW
User needs
Product space
Actual product’s behavior
Architecture/data flow
Module specifications
Algorithms
Code
What
How
What
How
What
How
What
How
What
How
What
How
15. 15
IMPORTANCE OF SOFTWARE REQUIREMENTS
• The hardest single part of building a software system is deciding what to build...No other
part of the work so cripples the resulting system if done wrong. No other part is
difficult to rectify later
• Fred Brooks
16. 16
EXAMPLES OF REQUIREMENTS - 1
• The system shall maintain records of all payments made to employees on accounts of
salaries, bonuses, travel/daily allowances, medical allowances, etc.
17. 17
EXAMPLES OF REQUIREMENTS - 2
• The system shall interface with the central computer to send daily sales and inventory
data from every retail store
18. 18
EXAMPLES OF REQUIREMENTS - 3
• The system shall maintain records of all library materials including books, serials,
newspapers and magazines, video and audio tapes, reports, collections of transparencies,
CD-ROMs, DVDs, etc.
19. 19
EXAMPLES OF REQUIREMENTS - 4
• The system shall allow users to search for an item by title, author, or by International
Standard Book Number
• The system’s user interface shall be implemented using a web browser
20. 20
EXAMPLES OF REQUIREMENTS - 5
• The system shall support at least twenty transactions per second
• The system facilities which are available to public users shall be demonstrable in ten
minutes or less
25. 25
FUNCTIONAL REQUIREMENTS - 2
• Statements of services the system should provide
• Reaction to particular inputs
• Behavior in particular situations
26. 26
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
27. 27
FUNCTIONAL REQUIREMENTS - 4
• Functional requirements should be complete and consistent
• Customers and developers usually focus all their attention on functional requirements
28. 28
FUNCTIONAL REQUIREMENTS EXAMPLE # 1
• The system shall solve a quadratic equation using the following formula
x = (-b+sqrt(b2
– 4*a*c))/2*a
29. 29
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.)
30. 30
FUNCTIONAL REQUIREMENTS EXAMPLE # 3
• The system shall provide appropriate viewers for the user to read documents in the
document store
31. 31
FUNCTIONAL REQUIREMENTS EXAMPLE # 4
• Every order shall be allocated a unique identifier (ORDER_ID) which the user shall use
to access that order
32. 32
FUNCTIONAL REQUIREMENTS EXAMPLE # 5
• The system shall allow customers to return non-perishable items within fifteen days of
the purchase. A customer must present the original sale receipt to return an item
33. 33
COMMENTS ON EXAMPLES
• Notice the level of detail in different requirements described above. Some are very
detailed compared to others
34. 34
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
35. 35
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
36. 36
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
37. 37
SUMMARY
• Requirements form the basis of all software engineering projects
• Functional requirements capture the behavioral aspects/functions of the proposed
automated system
• Functional requirements are the backbone of all software products
Editor's Notes
#2:Requirements are the foundation of every software product. If this activity is conducted firmly and correctly then it means you have lay down the foundation of a very successful and high quality software product. If it is not done correctly then it will result in a poorly developed software.
This is a very human and very cultural oriented process and we will talk about these issues.
#4:Defining what are requirement and what is mean by software requirements.
There is need to understand between these two words when we are developing high quality software. As most of you understand that most of the customers do not know what the requirements are? It is responsibility of the requirement engineer that understand, discover and elaborate the exact requirements that the customer has for a particular software.
Many customers want something in the software. The matter of fact is that customer do not understand the difference between wants and needs. Software engineers must have professionalism and training to understand the difference between two things and express them clearly to the customer. Determining real needs of a customer is very important for high quality software. It is true that customers pay for the software product but it is also true that software engineer has to live and work according to the code of ethics issued by IEEE computer society and ACM for their profession. It is very important to follow ethically business professionalism while discovering and documenting for the requirement.
#6:What vs. How: when we say this software product does this as compare to how it does. There is difference of understanding and differences of abstraction in these two statements. It is very important part of gathering requirements and documenting requirement. Many customers find it very convenient to describe that how things work instead of telling what things should be done? What is the future of the software product? When you start describing how things work as compare to what things do? You go into the mechanics of developing things which is not the intent and purpose of SR. So firmly state what SR describe? Are they describe the complete description of what the software system will do without describing how it will do…important point.
Understand the difference what the system does as compare how the system does it. Many professionals fall into this trap of describing how products are developed when they should be focus what are feature and functionality of this software. We should stay at what level?
#7:1. What is complete specs means?….what the system does, and it also means that when product is viewed by its user from different perspectives so requirement should describe all the possible aspects of software product from different perspectives.
2. External Behavior: The desired External behavior of software system has to be captured, has to be documented as it has to be understood by its users. The reason is that user can only understand product from its external behavior, they don’t know how the product is built, they don’t care how the product is built, they should not know how the product is built? they only use and judge the product by its external behavior. The external behavior will be that if you give it input how does it respond? Does it respond in the way expected or in erroneous way? Does it produce correct results or incorrect results? That is the external behavior. So the requirements must capture the external behavior of the software that one wants to built.
#8:As per the domain you may describe requirement at multiple levels of abstraction. They can be simple statements- For example I can say, I need a software which calculate the payroll of all employee on the other hand I can say this is the formula to calculate. The levels of the detail can be at a vey low level and very high level so document requirement correctly.
#9:Another thing that should be understood about requirement that it may be included in the contract…that is business contract, although it is not recommended but it may be included as part of contract and so on so again the requirements can be operating at different level of abstraction.
Construction Project
#11:A Condition which can be a constraint, capability is a functionality that must be met or possessed by a Software system ( What IEEE which is the flagship organization for computer and electronics professionals)
#12:Let say we developing Payroll System Example
People,
2. Another very important source is Documents (Company Laws and Tax laws/Regulations provided by the document)
3.Manual or an outdated Computer System that tells you how things operate in the company.
4. Issues like Provident funds, pensions funds included in domain or business area………………….Every Requirement Engineer must collaborate and gather requirement from these four source if you skip one of them then you are not going to fully understand the impact of requirements that you are going to collect.
#13:What vs. How dilemma:
What describe the policy matters or functionality & How… which is the mechanism……To develop mechanism for software is responsibility of Designer.
#16:It have different things which are covered in this requirement.
This is high level abstraction, it covers many things but not provides little information how things will be calculated?
#17:Again this requirement do not describe how system will interface. It just say that this should be done and not how things should be done?
This is again an example of well documented requirement.
#18:How things are done is not the part of this requirement.
#19:This requirement describing different parameters for search but not how search should be done.
Indicating that search can be done from anywhere but not that how this protocol or search mechanism should be implemented.
#20:This requirement capture the performance and efficiency of the system but not describing particular technology or hardware. It simply define that user expected response time.
Again second requirement deals with the efficiency or response time of the system.
There are the examples of valid software requirements. These do not provide mechanism to implement the requirement. These software requirements enable the developer to come up with design options so that these requirements can be met by the software product.
#24: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.
#25: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
#26: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
#27: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.
#28: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.
#30:This requirement is described at much higher level as compare to the two requirements discussed before.
