2. CHARACTERISTICS OF SRS
Following are the characteristics of a Good Software Requirement
Specification
Correctness: If your SRS covers all the needs that are expected
from the system than you may say that this SRS is correct.
You can get the accuracy of requirement through the user review.
Consistency: An SRS is said to be consistent if and only if no
requirement mentioned in the document are showing conflict.
2
3. CHARACTERISTICS OF SRS
Unambiguousness: SRS is said to be unambiguous when every
fixed requirement has only one interpretation.
Modifiability: SRS should be able to quickly obtain changes.
Note: Modification should be completely index and you should have
reference for the modification.
3
4. CHARACTERISTICS OF SRS
Verifiability: You verify here the final software meet the
requirement. So the SRS should be designed in a way that you can
verify it with final software.
Design Independence: Your SRS should not contain any detail
about design, It should be design independent. It will allow
engineers to chose the best design for the product.
Customer Understanding: SRS should not contain any
technical terminology, it should be easy to understand by
customer.
4
5. CHARACTERISTICS OF SRS
Black Box View: Your document should focus on the black box
view, Means avoid the technical things in the documents.
5
6. REQUIREMENT PRIORITIZATION IN AGILE
What are Requirements?
If a client want to develop a software, he may give you some
details what he want from the system.
All those details are the requirements of the client.
6
7. REQUIREMENT PRIORITIZATION IN AGILE
What are Requirement Prioritization?
Some time you don’t deliver the whole system at once, you
deliver the system in iterations.
Why?
Because the whole system will take time to get
developed and the client want some of its features at
early level so they san start using it ASAP!
Now the next thing you must cope with, what are the
features which client want at early level.
7
8. REQUIREMENT PRIORITIZATION IN AGILE
Sometimes the client demand which is not possible at
early stage some features are dependent on other.
So you make some criteria and prioritize the things you
will provide at early level.
For Example:
we go to buy a smartphone, there are lots of smartphones
available in the market with features some smartphones have
good camera but don’t have good battery timing some time a
smart phone provide you good battery timing but may be
there is lack of a good camera so you have to compromise
your beautiful selfie. 8
9. REQUIREMENT PRIORITIZATION IN AGILE
For Example count…
Now this is the point you will take a prioritization-based
decision either the camera is important for you or the battery
timings matters for you.
If you are working guy you will compromise the camera and
go for long lasting battery you take the decision and
prioritize the battery based on your need.
9
10. REQUIREMENT PRIORITIZATION IN AGILE
Things to Note first when prioritizing the requirements:
May be the most important functionality will not be the first
prioritization because it is expensive, and the lack of budget
is the client-side problem.
Possibly there will be more than one software stake holders
and different stakeholders have different priorities sometime.
Keep in mind the simple rule, As a requirement engineer you
have to prioritize the requirement under the constraints by
the feedback of stakeholders. 10
11. REQUIREMENT PRIORITIZATION IN AGILE
Techniques of Requirement Prioritization:
Negotiation Technique: In this technique requirement
engineer will work with the stakeholder, clients and all other
who will be the user of the software collect the requirements,
get feedback on the requirements negotiate with customer
e.g. what you want to provide the first, or agree them what is
better for them to get in start of the software.
Quantitative Technique: In this technique requirement
engineering should perform an analysis based on quantities
e.g.
11
12. REQUIREMENT PRIORITIZATION IN AGILE
Quantitative Technique count …
What is the budget of client for first feature needed in
software?
In how much time the client want the working software?
What are the financial benefits?
What are the risks?
How much level of risk we can bear on the current level?
12
13. UNIVERSITY MANAGEMENT SYSTEM
Practice Work
Few requirement from the client roughly:
Option to register a student
Option to submit student fee
Option to enroll student in a class
Option to upgrade the student class
Option to take attendance
Option to take exam
Option to generate result card
Option to see monthly income of University
Option to add daily base expense
Option to see all the expenses of the university on the end of the
month 13
14. UNIVERSITY MANAGEMENT SYSTEM
Monthly report of fee submission
Option to register Teacher
Option to Pay teacher.
Now the client wants to get the system on early basis and want
some features on priority basis.
So, you will make a priority table and work accordingly.
14
Color to Show Priority Priority
High
Medium
Low
15. UNIVERSITY MANAGEMENT SYSTEM
Requirements Organizational
Importance
Development
Effort
Priority Iteration
Option to register a
student
1st First
Option to submit student
fee
1st First
Option to enroll student
in a class
1st First
Option to upgrade the
student class
Last Last
Option to take attendance Negotiate Pending
Option to take exam Last Last
Option to generate result
card
Option to see monthly
income of University
15
16. UNIVERSITY MANAGEMENT SYSTEM
Requirements Organizational
Importance
Developmen
t Effort
Priority Iteration
Option to add daily base
expense
Option to see all the
expenses of the university
on the end of the month
2nd 2nd
Iteration
Monthly report of fee
submission
2nd 2nd
Iteration
Option to register teacher 1st 1st
Iteration
Option to pay teacher 2nd Iteration
16
