UNIT 2 Software Requirement Specifications SRS and Software

UNIT – 2 Software Requirement Specifications (SRS) and Software Project Management

Requirement Engineering Ø The process to gather the software requirements from client, analyze and document them is known as requirement engineering. Ø The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document. Ø Requirement Engineering Process is a four step process, which includes – Ø Feasibility Study Ø Requirement Gathering Ø Software Requirement Specification (SRS) Ø Software Requirement Validation

Feasibility study Ø This feasibility study is focused towards goal of the organization. Ø This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. Ø The output of this phase should be a feasibility study report that should contain comments and recommendations for management about whether or not the project should be undertaken.

Requirement Gathering Ø If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Ø Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

What is SRS? Ø SRS is an abbreviation of Software Requirement Specification. Ø A software requirements specification (SRS) is a document that captures complete description about how the system is expected to perform. Ø SRS is a document created by system analyst after the requirements are collected from various stakeholders. Ø The SRS provides the requirements in technical language so that they can be comprehended and useful by the software development team to project planning, design, coding, and testing. Ø It should also provide a realistic basis for estimating product costs, risks, and schedules. Ø It is usually signed off at the end of requirements engineering phase.

SRS Features SRS should come up with following features: Ø User Requirements are expressed in natural language. Ø Technical requirements are expressed in structured language, which is used inside the organization. Ø Design description should be written in Pseudo code. Ø Format of Forms and GUI screen prints. Ø Conditional and mathematical notations for DFDs etc.

Qualities of SRS Ø Correct Ø Unambiguous Ø Complete Ø Consistent Ø Prioritized Ø Verifiable Ø Modifiable Ø Traceable Types of Requirements:

The Institute of Electrical and Electronics Engineers (IEEE) publishes several dozen software engineering standards. One is called IEEE Std 830 -1998, IEEE Recommended Practice for Software Requirements Specifications 1. Introduction 1. 1 Purpose 1. 2 Document Conventions 1. 3 Intended Audience and Reading Suggestions 1. 4 Product Scope 1. 5 References 2. Overall Description 4. System Features 2. 1 Product Perspective 4. 1 System Feature 1 2. 2 Product Functions 4. 2 System Feature 2 (and so on) 2. 3 User Classes and Characteristics 5. Other Nonfunctional Requirements 2. 4 Operating Environment 5. 1 Performance Requirements 2. 5 Design and Implementation Constraints 5. 2 Safety Requirements 2. 6 User Documentation 5. 3 Security Requirements 2. 7 Assumptions and Dependencies 5. 4 Software Quality Attributes 3. External Interface Requirements 5. 5 Business Rules 3. 1 User Interfaces 6. Other Requirements 3. 2 Hardware Interfaces Appendix A: Glossary 3. 3 Software Interfaces Appendix B: Analysis Models 3. 4 Communications Interfaces Appendix C: To Be Determined List

Software Requirement Validation Ø After requirement specifications are developed, the requirements mentioned in this document are validated. Ø Requirements can be checked against following conditions Ø If they can be practically implemented Ø If they are valid and as per functionality and domain of software Ø If there any ambiguities Ø If they are complete Ø If they can be demonstrated

Software Requirements Ø Software requirements should be categorized in two categories: Ø Functional Requirements Ø Non-Functional Requirements Ø Requirements, which are related to functional aspect of software. Ø They define functions and functionality within and from the software system. Ø Examples Ø Search option given to user to search from various invoices. Ø User should be able to mail any report to management. Ø Users can be divided into groups and groups can be given separate rights. Ø Should comply business rules and administrative functions.

Software Requirements Non-Functional Requirements Ø Requirements, which are not related to functional aspect of software, fall into this category. Ø They are implicit or expected characteristics of software. Ø Non-functional requirements include Ø Security Logging Ø Configuration Performance Ø Interoperability Ø Accessibility Flexibility Storage Cost Disaster recovery

Software Requirements are categorized logically as Ø Must Have : Software cannot be said operational without them. Ø Should have : Enhancing the functionality of software. Ø Could have : Software can still properly function with these requirements. Ø Wish list : These requirements do not map to any objectives of software. Ø While developing software, Ø ‘Must have’ must be implemented, Ø ‘Should have’ is a matter of debate with stakeholders and negation, Ø ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements Ø UI is an important part of any software. Ø A software is widely accepted if it is Ø easy to operate Ø quick in response Ø effectively handling operational errors Ø providing simple yet consistent user interface Ø User acceptance depends upon how user can use the software. Ø UI is the only way for users to perceive the system. Ø A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way.

User Interface requirements User interface requirements are briefly mentioned below - Ø Content presentation Ø Easy Navigation Ø Simple interface Ø Responsive Ø Consistent UI elements Ø Feedback mechanism Ø Default settings Ø Purposeful layout Ø Strategically use of color and texture. Ø Provide help information Ø User centric approach Ø Group based view settings.

Software Project Management Ø All such business and environmental constraints bring risk in software development hence it is essential to manage software projects efficiently. Ø Triple constraints for software projects. Ø It is an essential part of software organization to deliver quality product, keeping the cost within client’s budget constrain and deliver the project as per scheduled. software project management is essential to incorporate user requirements along with budget and time constraints.

Software Management Activities Ø Software project management comprises of a number of activities, which contains planning of project, deciding scope of software product, estimation of cost in various terms, scheduling of tasks and events, and resource management. Ø Project management activities may include: Ø Project Planning Ø Scope Management Ø Project Estimation

Software Management Activities Project Planning Ø Software project planning is task, which is performed before the production of software actually starts. Ø It is there for the software production but involves no concrete activity that has any direction connection with software production; rather it is a set of multiple processes, which facilitates software production.

Software Management Activities Scope Management Ø Scope management is essential because it creates boundaries of the project by clearly defining what would be done in the project and what would not be done. Ø This makes project to contain limited and quantifiable tasks, which can easily be documented. During Project Scope management, it is necessary to - Ø Define the scope Ø Divide the project into various smaller parts for ease of management. Ø Verify the scope Ø Control the scope by incorporating changes to the scope

Software Management Activities Project Estimation Ø For an effective management accurate estimation of various measures is a must. Ø With correct estimation managers can manage and control the project more efficiently and effectively. Project estimation may involve the following: Ø Software size estimation Ø Effort estimation Ø Time estimation Ø Cost estimation

Project Estimation Software size estimation Ø Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by calculating number of function points in the software. Ø Lines of code depend upon coding practices and Function points vary according to the user or software requirement. Effort estimation Ø The managers estimate efforts in terms of personnel requirement and man-hour required to produce the software. Ø For effort estimation software size should be known. Ø This can either be derived by managers’ experience, organization’s historical data or software size can be converted into efforts by using some standard formulae.

Project Estimation Time estimation Ø Once size and efforts are estimated, the time required to produce the software can be estimated. Ø Efforts required is segregated into sub categories as per the requirement specifications and interdependency of various components of software. Ø Software tasks are divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). Ø The tasks are scheduled on day-to-day basis or in calendar months. Ø The sum of time required to complete all tasks in hours or days is the total time invested to complete the project.

Project Estimation Cost estimation Ø This might be considered as the most difficult of all because it depends on more elements than any of the previous ones. Ø For estimating project cost, it is required to consider - Ø Size of software Ø Software quality Ø Hardware Ø Additional software or tools, licenses etc. Ø Skilled personnel with task-specific skills Ø Travel involved Ø Communication Ø Training and support

Classes of Software Projects Ø Organic: if the project deals with developing a well understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar types of projects. Ø Semidetached: if the development consists of a mixture of experienced and inexperienced staff. Team members may have limited experience on related systems but may be unfamiliar with some aspects of the system being developed. Ø Embedded: if the software being developed is strongly coupled to complex hardware, or if the tough regulations on the operational procedures exist.

Constructive Cost Model (COCOMO) Ø The Constructive Cost Model (COCOMO) is a procedural software cost estimation model developed by Barry W. Boehm. Ø The model parameters are derived from fitting a regression formula using data from historical projects. Ø COCOMO is used to estimate size, effort and duration based on the cost of the software. Three types of COCOMO Ø Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy is limited due to its lack of factors to account for difference in project attributes. Ø Intermediate COCOMO takes these Cost Drivers into account. Ø Detailed COCOMO additionally accounts for the influence of individual project phases.

Basic COCOMO Ø The basic COCOMO equations take the form Ø Effort Applied (E) = a 1(KLOC)a 2 [Person-Month] Ø Development Time (D) = b 1 (Effort Applied) b 2 [Months] Software project a 1 a 2 b 1 b 2 Organic 2. 4 1. 05 2. 5 0. 38 Semi-detached 3. 0 1. 12 2. 5 0. 35 Embedded 3. 6 1. 20 2. 5 0. 32

Basic COCOMO Example Ø Assume that the size of an organic type software product has been estimated to be 32, 000 lines of source code. Assume that the average salary of software engineers be Rs. 15, 000/- per month. Determine the effort required to develop the software product and the nominal development time. Effort = 2. 4 х (32)1. 05 = 91 PM Nominal development time = 2. 5 х (91)0. 38 = 14 months Cost required to develop the product = 14 х 15, 000 = Rs. 210, 000/-

Intermediate COCOMO Ø The basic COCOMO model assumes that effort and development time are functions of the product size alone. Ø However, a host of other project parameters besides the product size affect the effort required to develop the product as well as the development time. Ø The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on various attributes of software development. Ø In general, the cost drivers can be classified as being attributes of the following items: Product, Computer, Personnel, Development Environment

Intermediate COCOMO Ratings Very Low Nominal High Very High Extra High 0. 75 0. 70 0. 88 0. 94 0. 85 1. 00 1. 15 1. 08 1. 15 1. 40 1. 16 1. 30 1. 65 1. 00 1. 11 1. 06 1. 30 1. 21 1. 66 1. 56 Volatility of the virtual machine environment 0. 87 1. 00 1. 15 1. 30 Required turnabout time Personnel attributes Analyst capability Applications experience Software engineer capability Virtual machine experience Programming language experience Project attributes 0. 87 1. 00 1. 07 1. 15 1. 46 1. 29 1. 42 1. 21 1. 14 1. 19 1. 13 1. 17 1. 10 1. 07 1. 00 0. 86 0. 91 0. 86 0. 90 0. 95 0. 71 0. 82 0. 70 Application of software engineering methods 1. 24 1. 10 1. 00 0. 91 0. 82 Use of software tools Required development schedule 1. 24 1. 23 1. 10 1. 08 1. 00 0. 91 1. 04 0. 83 1. 10 Cost Drivers Product attributes Required software reliability Size of application database Complexity of the product Hardware attributes Run-time performance constraints Memory constraints

Intermediate COCOMO Ø The Intermediate Cocomo formula now takes the form: E=ai(KLo. C)bi(EAF) Ø where E is the effort applied in person-months, Ø KLo. C is the estimated number of thousands of delivered lines of code for the project, and Ø EAF is the factor calculated from cost table. Software project ai bi Organic 3. 2 1. 05 Semi-detached 3. 0 1. 12 Embedded 2. 8 1. 20

Detailed COCOMO Ø Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc. ) of the software engineering process. Ø The detailed model uses different effort multipliers for each cost driver attribute. Ø In detailed COCOMO, the whole software is divided into different modules and then we apply COCOMO in different modules to estimate effort and then sum the effort. Ø The effort is calculated as a function of program size and a set of cost drivers are given according to each phase of the software life cycle.

Project Management Tools Ø The risk and uncertainty rises with respect to the size of the project, even when the project is developed according to set methodologies. Ø There are tools available, which aid for effective project management. A few are described – Ø Gantt Chart Ø PERT Chart Ø Resource Histogram Ø Critical Path Analysis

Gantt Chart Ø Gantt charts was devised by Henry Gantt (1917). Ø It represents project schedule with respect to time periods. Ø It is a horizontal bar chart with bars representing activities and time scheduled for the project activities.

PERT Chart Ø PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network diagram. Ø It is capable of graphically representing main events of project in both parallel and consecutive way. Ø Events, which occur one after another, show dependency of the later event over the previous one.

Resource Histogram Ø This is a graphical tool that contains bar or chart representing number of resources (usually skilled staff) required over time for a project event (or phase). Ø Resource Histogram is an effective tool for staff planning and coordination.

Critical Path Analysis Ø This tools is useful in recognizing interdependent tasks in the project. Ø It also helps to find out the shortest path or critical path to complete the project successfully. Ø Like PERT diagram, each event is allotted a specific time frame. Ø This tool shows dependency of event assuming an event can proceed to next only if the previous one is completed. Ø The events are arranged according to their earliest possible start time. Ø Path between start and end node is critical path which cannot be further reduced and all events require to be executed in same order.