2. Organization of SRS
Functional Requirements: They describe what has to do and what the software should not do.
They specify which outputs should be produced from the given inputs.
This includes specifying the validity checks on the input.
System should specify the behavior of the system for invalid inputs .
Eg –airline reservation

3. Performance Requirements
Static Requirement
The number of terminals to be supported
The number of Simultaneous users to be supported.
Dynamic Requirement: Execution behavior of the system.
Includes response time (Expected time for completion of an operation under specified circumstances) and throughput (Expected no of operations that can be performed in a unit time).

4. Design Constraints
There are number of factors in client’s environment that may restrict the choices of a designer.
Standard Compliance: report format
Hardware Limitations: The s/w may have to operate on some existing or predetermined hardware, thus imposing restrictions on the design.

5. Reliability and Fault Tolerance: Requirements about system behavior in the face of certain kinds of faults is specified. (Detailing what the system should do if some failure occurs to ensure certain properties).
Fault Tolerance-continue operating properly in the event of the faluire.
Security: passwords , different kinds of access requirements

6. External Interface Requirements
User interface- The characteristics of each user interface of software product should be specified. Hardware Interface-Interface b/w software and hardware.

7. Validation
The basic objective of the requirements validation activity is to ensure that the SRS reflects the actual requirements accurately and clearly.
The longer an error remains undetected, the greater the cost of correcting it. Hence it is extremely desirable to detect errors in the requirements before the design and development of software begin.

8. Errors that typically occur in an SRS-
Omission- some user requirement is simply not included in the SRS.
Inconsistency- contradictions within the requirements.
Incorrect facts- fact recorded in SRS is not correct.
Ambiguity- requirements having multiple meaning.
Requirements review- group

9. Planning- Metrics
Size – The commonly used size metric for requirements is the size of text of the SRS.
The size could be in number of pages, paragraphs, functional requirements. (differ)
Function points- It is the most widely used measures of software size. The basis of function points is that the “Functionality” of the system, i.e what the system performs, is the measure of the system size.

10. External Inputs- info entering the system
External Outputs- Info leaving the system
Enquires- Requests for instant access to info
Internal logical files-Information held within the system.
External interface files- Information held by other systems that is used by the system being analyzed

11. Function type
Simple/low
Average
Complex
External Input 3 4 6
External Output 5 7
Logical Internal file 10 15
External interface file
External inquiry

12. UFP(unadjusted)= ∑ ∑ZijWij
i=1 i=5, j=1 j=3
Wij= It is entry of ith row and jth coloumn
Zij= It is the count of the number of functional units of type i that have been classified as having the complexity corresponding to column j.
CAF(complexity adjustment factor)= *∑F
Fi=1 to 14
FP=UFP*CAF

13. COCOMO(constructive cost model)
It is an cost estimation model
Three models of s/w development are considered in this model:
Organic, semi-detached, embedded
Organic model- small team of experienced developers develops s/w in a very familiar environment.

14. Mode
Project size
Nature of project
Innovation
Deadline of the project
Development environment
Organic
2-50 KLOC
Small size project
Little
Not tight
Familiar
Semi-detached
50-300KLOC
Medium size project
Medium
Embedded
Over 300KLOC
Large projects
Significant
Tight
Complex

15. System a b c d
Organic
Semidetached
Embedded
Cost Drivers- Multiplying factors
EAF= Effort adj factor

16. E= a(KLOC)*EAF raise to the power b
D=c(E) raise to the power of d
Effort applied in a person month
Development time in a months
Average staff size(SS)= E/D persons
Productivity P=KLOC/E

17. Putnam-Norden-Rayleigh
Provides an indication of the relationship b/w effort applied and delivery time for a s/w project.
Effort
Cost
Development Time Td To

18. To= optimal development time(in terms of cost) – least effort
Td= nominal delivery time for schedule
If we move to left of “To “ , the curve raises non linearly
Tmin= .75td
If we attempt further compression the project move into “the impossible region” and risk failure becomes very high.

19. L=P*E power 1/3*t power 4/3
E- effort
P- productivity
E= (L power3)/(Ppower3 * t power4)

20. Risk management Tomorrow’s problem is today’s risk.
It is an attempt to minimize the chances of failure caused by unplanned events.
The aim of RM is not to avoid getting into projects that have risks but to minimize the impact of risks in the projects that are undertaken.

21. Risk mgt concepts
Risk- It is defined as an exposure to the chance of injury or loss. i.e risk implies that there is a possibility that something negative may happen .
In the concepts of software projects, -ve implies that there is an adverse effect on cost , quality.
Risk management is an area that the impact of risks on cost, quality is minimal.

22. Risk Identification
Risk Assessment
Risk Analysis
Risk Prioritization
Risk mgt
Risk mgt Planning
Risk Resolution
Risk Control
Risk Monitoring

23. Risk Assessment
Due to nature of project uncertainties are highest near the beginning of project. Due to this RA is most needed in the starting phases of the project.
Risk identification can be facilitated with the help of checklist of common risk areas of software projects.
It includes checklist, surveys, brainstorming.

24. Risk Analysis involves examining how project outcomes might change with modification of risk input variables.
Risk prioritization helps the project focus on its most severe risks.

25. Risk control
It is the process of managing risks to achieve the desired outcomes.
The goal of risk mgt is to prepare a plans so that the consequences are minimal.
Risk mgt planning produces a plan for dealing with each significant risk.
Resolution- executions of plans for dealing with each risks.
Monitoring means periodically revaluating the risks.

26. A practical Risk mgt Approach (example)
1. For each risk, rate the probability of its happening as low, medium, high
2.For each risk, assess its impact on the project as low, medium, or high.
3.Rank the list based on probability and effects on the project, eg- high probability, high impact item will have higher rank.
4. Select the risks items for mitigation(comprises active measures that have to be performed to minimize the impact of risks.

27. Seq no
Risk
Prob
Impact
Exp
Mitigation Plan 1
Failure to meet the high performance
High
Study white papers and guidelines, train team 2
Lack of peoples with right skills
Med
Review prototype with customer, Develop coding practices 3
Complexity of application
med
Deploy persons with prior experience with the domain.