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

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).

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.

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

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.

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.

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

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.

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

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

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)= 0.65+0.01*∑F Fi=1 to 14 FP=UFP*CAF

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.

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

System a b c d Organic 3.2 1.05 2.5 .38 Semidetached 3 1.12 2.5 .35 Embedded 2.8 1.2 2.5 .32 Cost Drivers- Multiplying factors EAF= Effort adj factor

E= a(KLOC) raise to the power b *EAF 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

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

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.

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

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.

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.

Tomorrow’s problem is today’s risk. It is a process of managing risks to achieve the desired outcomes.