1 / 29

Organization of SRS

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.

rbrennan
Télécharger la présentation

Organization of SRS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

  10. UFP(unadjusted)= ∑ ∑ZijWij • i=1 i=5, j=1 j=3 • Wij= It is entry of ith row and jthcoloumn • 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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related