This action might not be possible to undo. Are you sure you want to continue?
What is Software Requirement? Ans.: In software engineering, requirements analysis is used for determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders or users. Systematic requirements analysis is also known as requirements engineering. It is sometimes referred loosely by names such as requirements gathering, requirements capture, or requirements specification. Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Conceptually, requirements analysis includes three types of activity:
Requirements : the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Analyzing Requirements : determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
Recording Requirements : Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
What is Software Requirements Specification (SRS)? Ans.: A Software Requirements Specification (SRS) is a complete description of the behaviour of the system to be developed. It includes a set of use cases that describe all the interactions that the users will have with the software. Use cases are also known as “functional requirements”. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. “Non-functional requirements” are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).
Software requirements is a sub-field of Software engineering that deals with the elicitation, analysis, specification, and validation of requirements for software . The software requirement specification (SRS) document generates all necessary requirements for project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with project team and the customer. An SRS clearly defines the following: 1. External interfaces of the system: They identify the information which is to flow 'from and to' the system. 2. Functional and nonfunctional requirements of the systems. They stand for the finding of run-time requirements. 3. Design constraints A Software Requirements Specification (SRS) - a requirements specification for a software system - is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).
Requirement gathering is usually the first part of any software product. This stage starts when you are thinking about developing software. In this phase, you meet customers or prospective customers, analyzing market requirements and features that are in demand. You also find out if there is a real need in the market for the software product you are trying to develop. In this stage, marketing and sales people or people who have direct contact with the customers do most of the work. These people talk to these customers and try to understand what they need. A comprehensive understanding of the customers‘ needs and writing down features of the proposed software product are the keys to success in this phase. This phase is actually a base for the whole development effort. If the base is not laid correctly, the product will not find a place in the market. If you develop a very good software product which is not required in the market, it does not matter how well you build it. You can find many stories about software products that failed in the market because the customers did not require them. An effective requirements gathering process is perhaps the most critical driver of software project success. Getting the requirements right – and getting the right requirements – can mean the difference between a successful project – one that satisfies the needs of its users and is delivered on-time and on-budget – and one that fails. It should come as no surprise that effective requirements gathering involves much more than asking business users what they want and need. It is a complex process that involves users and system designers in a collaborative effort that explores both functional requirements and the new possibilities that technology offers. The great challenge of the requirements process is finding a
The success of any new software project is critically dependent on the initial ―discovery‖ or ―requirements analysis‖ phase of the project. If you want competitive bids from software development companies. Bids will be more accurate because potential vendors have clear information on which to base their proposals. related to identified business needs or opportunities. structural. and generally ineffective as communications devices Requirements Analysis: Requirements analysis in systems engineering and software engineering. Better evaluation of the project. Leapfrog a generation of development. It‘s far easier to accurately estimate a development project after the requirements have been clearly established. functional. actionable. With an accurate estimate of cost and completion date. A well-executed requirements analysis often reveals opportunities to streamline or evolve existing business practices. because all bidders will be responding to the same written request. Requirements can be architectural. and defined to a level of detail sufficient for system design. and then quickly moves to discussions about parts of the technology solution. All too often the requirements process begins with a few key questions about the business need. producing a result that precisely solves the business problem. benefit and to position the proposed system in a company‘s overall strategic plan. measurable. your evaluation of their responses can be on a more ―apples to apples‖ basis. Higher-quality bidding from vendors. it is much easier to evaluate cost vs. In addition. Requirements analysis is critical to the success of a development project. taking account of the possibly conflicting requirements of the various stakeholders. encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product. This is much easier said than done.way to uncover and capture the needs of the business and communicate those needs to a software development team in a language and style that facilitates the software design process. Sometimes one or two rounds of requirements analysis followed by a re-evaluation of objectives can help you to skip a generation in-house development—so you ultimately end up with ―version 2‖ of the desired system instead of version 1. behavioral. Requirements must be documented. saving considerable cost and time. such as beneficiaries or users. Traditional requirements documents are a confusing combination of business and technology language. misunderstood by most. and non-functional. As a result they are time consuming for the careful reader. Steps in the Requirements Analysis Process : . a good requirements study is essential. Here are some reasons requirements analysis is often treated as a separate project—distinct from design and implementation of a software system: More accurate cost estimate. testable.
The level of detail of the requirements list is based on the number and size of user groups. often with conflicting goals. Strong communication and people skills along with sound programming knowledge are prerequisites for an expert Requirements Analyst. organizational charts.I. market research and competitor analysis were also used extensively in Requirements Elicitation. Other methods like flowcharting of business processes and the use of existing documentation like user manuals. II. Fix system boundaries This initial step helps in identifying how the new application integrates with the business processes. Identify the customer In more recent times there has been a focus on identifying who the ‗users‘ or ‗customers‘ of an application are. Some of the current Requirements Elicitation tools in use are: Prototypes Use cases Data flow diagrams . on-site analysis. Referred to broadly as the ‗stake holders‘. the degree of complexity of business processes and the size of the application. Requirements elicitation Information is gathered from the multiple stakeholders identified. b) Tools used in Requirements Elicitation Traditional methods of Requirements Elicitation included stakeholder interviews and focus group studies. The Requirements Elicitation Process should focus on the wish-list of this defined group to arrive at a valid requirements list. The Requirements Analyst draws out from each of these groups what their requirements from the application are and what they expect the application to accomplish. how it fits into the larger picture and what its scope and limitations will be.However current research in Software Requirements Analysis Process has thrown up modern tools that are better equipped to handle the complex and multilayered process of Requirements Elicitation. these indicate the group or groups of people who will be directly or indirectly impacted by the new application. By defining in concrete terms who the intended user is. Considering the multiple stakeholders involved. the list of requirements gathered in this manner could run into pages. process models and systems or process specifications. the Requirements Analyst knows in advance where he has to look for answers. a) Problems faced in Requirements Elicitation Ambiguous understanding of processes Inconsistency within a single process by multiple users Insufficient input from stakeholders Conflicting stakeholder interests Changes in requirements after project has begun A Requirements Analyst has to interact closely with multiple work-groups. to arrive at a bona fide requirements list. interviews with end-users. III.
A written requirements document is critical so that its circulation is possible among all stakeholders including the client. a structured analysis of these can be done after modeling the requirements. analogical and case-based reasoning. unambiguous terms. consistency checking. knowledge-based critiquing. modeled and analyzed should be documented in clear. and a Technical/Systems Analyst. if any Contract between the client and development team Basis for systems design for the development team Bench-mark for project managers for planning project development lifecycle and goals Source for formulating test plans for QA and testing teams Resource for requirements management and requirements tracing Basis for evolving requirements over the project life span Software requirements specification involves scoping the requirements so that it meets the customer‘s vision. hardware and database design. Requirements Analysis Process Once all stakeholder requirements have been gathered. It describes the function (Functional and Non-Functional specifications) of the system. Requirements Specification serves as a starting point for software. who is likely to approach the situation in technical terms. automated reasoning. addressing the Application Development Team and QA and Testing Team. performance of the system and the operational and user-interface constraints that will govern system development. It is the result of collaboration between the end-user who is often not a technical expert. Current requirements engineering practices reveal that a well-designed. The software requirements specification is a document that lists out stakeholders‘ needs and communicates these to the technical community that will design and build the system.expressed as a programming or mathematical model. precise language with plain text and use cases. Requirements Specifications may be documented separately as User Requirements . the development and testing teams. user-groups. VI. The challenge of a well-written requirements specification is to clearly communicate to both these groups and all the sub-groups within. Requirements Management .written in clear. Transition process diagrams User interfaces IV. V. for the benefit of the customer and end-user System Requirements . once elicited. To overcome this. Requirements Specification Requirements. clearly documented Requirements Specification is vital and serves as a: Base for validating the stated requirements and resolving stakeholder conflicts. Some of the Software Requirements Analysis techniques used are requirements animation.
validation and traceability of requirements. These lists create a false sense of mutual understanding between the stakeholders and developers. the number of (different) interpretations of the envisioned system increase. due to the nature of these lists.Requirements Management is the comprehensive process that includes all aspects of software requirements analysis and additionally ensures verification. For a large system can provide a high level description. However. Strengths and weaknesses : Strengths: Provides a checklist of requirements. Provide a contract between the project sponsor(s) and developers. these documents speak in generality. but the devil. These requirements lists are no help in system design. Effective requirements management practices guarantee that all system requirements are stated unambiguously. Data Flow Diagram (DFD) : . Weaknesses: Such lists can run to hundreds of pages. as they say. This abstraction increases the likelihood of misinterpreting the requirements. Such requirements lists abstract all the requirements and so there is little context This abstraction makes it impossible to see how the requirements fit or work together. This abstraction means that it's extremely difficult to be sure that you have the majority of the requirements. since they do not lend themselves to application. removing one item out of context can render an entire use case or business requirement useless. that omissions and errors are corrected and that evolving specifications can be incorporated later in the project lifecycle. while a list does make it easy to prioritize each individual item. as more people read them. Necessarily. This abstraction makes it difficult to prioritize requirements properly. Developers can use these discovered requirements to renegotiate the terms and conditions in their favour. they inevitably miss out crucial requirements which are identified later in the process. These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. is in the details. It is virtually impossible to read such documents as a whole and have a coherent understanding of the system.
There are several common modeling rules that I follow when creating DFDs: 1. DFDs can also be used for the visualization of data processing (structured design). and how the system will be implemented. It is therefore quite different from a flowchart. via an internal process. which shows the flow of control through an algorithm. Advantages of data flow diagrams : It gives further understanding of the interestedness of the system and sub-systems It is useful from communicating current system knowledge to the user Used as part of the system documentation files Dataflow diagram helps to substantiate the logic underlining the dataflow of the organization It gives the summary of the system DFD is very easy to follow errors and it is also useful for quick reference to the development team for locating and controlling errors Disadvantages of data flow diagram : DFD is likely to take many alteration before agreement with the user Physical consideration are usually left out It is difficult to understand because it ambiguous to the user who have little or no knowledge .On a DFD. With a data flow diagram. Each data store must be involved with at least one data flow. 4. data items flow from an external data source or an internal data store to an internal data store or an external data sink. The old system's dataflow diagrams can be drawn up and compared with the new system's data flow diagrams to draw comparisons to implement a more efficient system. users are able to visualize how the system will operate.A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. 5. allowing a reader to determine what operations will be performed. A DFD provides no information about the timing of processes. but not what kinds of data will be input to and output from the system. and under what circumstances. in what order. All processes must have at least one data flow in and one data flow out. or about whether processes will operate in sequence or in parallel. Data flow diagrams can be used to provide the end user with a physical idea of where the data they input ultimately has an effect upon the structure of the whole system from order to dispatch to report. nor where the data will be stored (all of which are shown on a DFD). 3. How any system is developed can be determined through a data flow diagram. what the system will accomplish. A data flow must be attached to at least one process. 2. All processes should modify the incoming data. producing new forms of outgoing data. nor where the data will come from and go to. Each external entity must be involved with at least one data flow.
Data Flow Diagram Symbols : Example of a Data Flow Diagram : .
contents. plus additional details. There is no . the other will automatically change. and conventions of one or more databases This typically includes the names and descriptions of various tables and fields in each database.Some important things to note are: The two links labelled "Student Information" have been mapped to the same data flow. Most objects in Visual Case can easily be mapped to other entities The processes are all high level tasks that could be exploded into sub-data flow diagrams that clarify and further specify the task The data flows are all labelled with the information that is being transferred Data Dictionary: A data dictionary. usage. like the type and length of each data element. If you change the name of one.Above is an example of a data flow diagram created with Visual Case. as defined in the IBM Dictionary of Computing. is a "centralized repository of information about data such as meaning. origin. or metadata repository. The term may have one of several closely related meanings pertaining to databases and database management systems (DBMS): a document describing a database or collection of databases an integral component of a DBMS that is required to determine its structure a piece of middleware that extends or supplants the native data dictionary of a DBMS Documentation: Database users and application developers can benefit from an authoritative data dictionary document that catalogs the organization. relationships to other data. and format‖.
universal standard as to the level of detail in such a document. while others use diagrams and flow charts to display all their information. For example. Middleware : In the construction of database applications. scripts can be deployed to export data from the database to the document. xml files.e. The only prerequisite for a data dictionary is that it should be easily searchable. to handwritten notes. There is always the option of manually creating these documents as well. i.. spreadsheets. the meta-data. not the requirements of a typical application. all the information required to create the data dictionary must be identified and recorded in the design documents. text…) Brief description of the expected data for each field Length of the field Default value for that field Is the field Nullable or Not Nullable Constraints that apply to each field. it can be useful to introduce an additional layer of data dictionary software. Such a "high-level" data dictionary may offer additional features and a degree of flexibility that goes beyond the limitations of the native "low-level" data dictionary. . whose primary purpose is to support the basic functions of the DBMS. Creating the Data Dictionary : First. Some database administrators prefer to create simple text files. but it is primarily a weak kind of data. it should be possible to directly export the data in them to the desired format for the data dictionary. i. the only applicable rule for storage of a data dictionary is that it should be at a convenient location that is easily accessible to all users of the database. middleware. A data dictionary is an integral part of a database. Even without the use of such tools. date. easy access to the type of data that they should expect to see in every table. row and column of the database. Meta-data differs from table to table. an additional table in the database itself.e. If the design documents are in a compatible format. accurate and easily accessible. Any well-designed database will surely include a data dictionary – it provides database administrators and other users. Again. if any Format and Storage : There exists no standard format for creating a data dictionary. without actually accessing the database. It is the duty of the database administrator to make sure that this document is always up to date. and would make creation of the data dictionary simpler. which holds information about the database and the data that it stores. applications like Microsoft Visio allow creation of the database directly from the design structure. which communicates with the underlying DBMS data dictionary. The types of files used to store data dictionaries range from text files. Some of the typical components of a data dictionary entry are: • • • • • • • • Name of the table Name of the fields in each table Data type of the field (integer.
to help identify a strategy most likely to reach a goal.commonly represented by squares 2. In scenarios involving large databases. Advantages : Are simple to understand and interpret. Decision nodes . If a given result is provided by a model. including chance event outcomes. Another use of decision trees is as a descriptive means for calculating conditional probabilities. when a new user is introduced to the system.represented by triangles . When the decisions or consequences are modelled by computational verb. then we call the decision tree a computational verb decision tree. People are able to understand decision tree models after a brief explanation. Have value even with little hard data. identifying table structures and types becomes simpler.represented by circles 3. Important insights can be generated based on experts describing a situation (its alternatives. and utility. where it is not possible for an administrator to completely remember specific bits of information about thousands of fields. probabilities. or a new administrator takes over the system. It is one way to display an algorithm. End nodes . specifically in decision analysis. a data dictionary becomes a crucial necessity Decision Tree: A decision tree is a decision support tool that uses a tree-like graph or model of decisions and their possible consequences. and costs) and their preferences for outcomes. Also. resource costs. the explanation for the result is easily replicated by simple math.Advantages of a Data Dictionary : The primary advantage of creating an informative and welldesigned data dictionary is that it exudes clarity on the rest of the database documentation. Can be combined with other decision techniques. Use a white box model. Chance nodes . A decision Tree consists of 3 types of nodes:1. Decision trees are commonly used in operations research.
conditional. END. END REPEAT. OPEN. DO WHILE. DO UNTIL. ELSE IF. EOT. Operation statements written as English phrases executed from the top down 2. Reject all loan applications in all other cases. FOR. END UNTIL. WHILE. AND. Repetition blocks indicated by keywords such as DO. IF customer has a Bank Account THEN IF Customer has no dues from previous account THEN Allow loan facility ELSE IF Management Approval is obtained THEN Allow loan facility ELSE . WITH. REPEAT. WRITE. WHILE. XOR. END WHILE. IF. and ELSE 3. If a customer has an account with the bank but some amount is outstanding from previous loans then loan will be granted if special approval is given. 5. ELSE THEN. EOF. 2. READ. DELETE. 4. LT. Conditional blocks indicated by keywords such as IF. UNTIL. CASE. TRUE. GET. Structured English or "pseudocode" consists of the following elements: 1. GE. 3. 3. END IF. ELSE. 2. Thus structured English aims at getting the benefits of both the programming logic and natural language. SO. FILE. If a customer has an account with the bank and had no loan outstanding. GT. Program logic helps to attain precision while natural language helps in getting the convenience of spoken languages. THEN.RETURN Example of Structured English : A bank will grant loan under the following conditions 1. EQUAL. Statements should be clear and unambiguous Use one line per logical element All logic should be expressed in operational. IF ELSE.Structured English: Structured English is the use of the English language with the syntax of structured programming. STOP. DO. BEGIN. NOT. THEN. EXIT. CREATE. PUT. LE. UPDATE. FALSE. loan will be granted. OR. and UNTIL Use the following guidelines when writing Structured English: 1. CLOSE. and repetition blocks Logical blocks should be indented to show relationship Keywords should be capitalized Examples of common keywords START. IF THEN.
Only those conditions should be selected which have the potential to either occur or not but partial occurrences are not permissible. For every N number of conditions there are 2*2*2…. (N times) combinations to be considered. 1. 3. Determine the most possible steps that can take place under varying conditions and not just under current condition. This will identify the conditions involved in the decision. The upper right quadrant contains the condition rules ofr alternatives. For the conditions that are immaterial a hyphen "-" is generally put. Decision table is further simplified by eliminating and consolidating certain rules. The steps of building the concerned tables are given below. Entries in a decision table are filled as Y/N and action entries are generally marked as "X". separated into four separate quadrants. . A decision table is a table with various conditions and their corresponding actions. 2.Reject ENDIF ENDIF ELSE Reject ENDIF Decision Tables: Decision tables. This step will identify the actions. 4. associate conditions with actions to perform. like flowcharts and if-then-else and switch-case statements. but in many cases do so in a more elegant way. A decision table is a table composed of rows and columns. The lower left quadrant contains the actions to be taken and the lower right quadrant contains the action rules. Conditions Actions Condition Alternatives Action Entries The upper left quadrant contains the conditions. Calculate all the possible combinations of conditions. Impossible rules are eliminated. These rules can be consolidated into a single rule. Firstly figure out the most essential factors to be considered in making a decision. There are certain conditions whose values do not affect the decision and always result in the same action. Fill the decision rules in the table.
.As such. and ultimately the prospects for success. opportunities and threats as presented by the environment. You also need to assess your competition and figure out how much money you need to start your business and keep it running until it is established. a well-designed feasibility study should provide a historical background of the business or project. where. the two criteria to judge feasibility are cost required and value to be attained. financial data. marketing research and policies. and to whom you intend to sell a service or product.Generally. accounting statements. feasibility studies precede technical development and project implementation. description of the product or service. In its simplest term. legal requirements and tax obligations. details of the operations and management. Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture.Feasibility Study: A feasibility study looks at the viability of an idea with an emphasis on identifying potential problems and attempts to answer one main question: Will the idea work and should you proceed with it? Before you begin writing your business plan you need to identify how. the resources required to carry through.
personnel and expertise. and 2. a data processing system must comply with the local Data Protection Acts. Programs. hardware.Five common factors (TELOS) : Technology and system feasibility : The assessment is based on an outline design of system requirements in terms of Input. . are the project deadlines reasonable? Some projects are initiated with specific deadlines. e. Fields. the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. then the decision is made to design and implement the system. the following should be taken to consideration: A brief description of the business The part of the business being examined The human and economic factor The possible solutions to the problems Economic feasibility : Economic analysis is the most frequently used method for evaluating the effectiveness of a new system. Output. This is an analysis of the costs to be incurred in the system and the benefits derivable out of the system. in terms of software. trends. Technological feasibility is carried out to determine whether the company has the capability. If benefits outweigh costs. which can be categorized as follows: 1. to handle the completion of the project when writing a feasibility report.Time-based study: This is an analysis of the time required to achieve a return on investments. Schedule feasibility is a measure of how reasonable the project timetable is. in order to estimate whether the new system will perform adequately or not. Schedule feasibility : A project will fail if it takes too long to be completed before it is useful. Development costs. Legal feasibility : Determines whether the proposed system conflicts with legal requirements.Cost-based study: It is important to identify cost and benefit factors. You need to determine whether the deadlines are mandatory or desirable. Operating costs. More commonly known as cost/benefit analysis. etc.g. This can be quantified in terms of volumes of data. Processes. Given our technical expertise. Typically this means estimating how long the system will take to develop. and if it can be completed in a given time period using some methods like payback period. An entrepreneur must accurately weigh the cost versus benefits before taking an action. and Procedures. Operational feasibility : Operational feasibility is a measure of how well a proposed system solves the problems. frequency of updating. and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development.
whether it interferes with normal business operations. Establishing programmatic and administrative objectives against which possible responses will be evaluated. Preparing concise functional requirements of an acceptable response. Financial feasibility : In case of a new project. office or mixed-use project. . Jurisdictions often require developers to complete feasibility studies before they will approve a permit application for retail. For example. Resource feasibility : This involves questions such as how much time is available to build the new system. the project's alternatives are evaluated for their impact on the local and general culture. housing. commercial. Market Feasibility takes into account the importance of the business in the selected area.financial viability can be judged on the following parameters: Total estimated cost of the project Financing of the project in terms of its capital structure.Other feasibility factors : Market and real estate feasibility : Market Feasibility Study typically involves testing geographic locations for a real estate development project. Developing an understanding of the organizational. Further an enterprise's own culture can clash with the results of the project. Identifying and evaluating possible alternative responses with respect to the established objectives. Developing an understanding of a problem (or opportunity) in terms of its effect on the agency's mission and programs. and technical environment within which a response to the problem or opportunity will be implemented. 4. Developers often conduct market studies to determine the best location within a jurisdiction. and usually involves parcels of real estate land. managerial. environmental factors need to be considered and these factors are to be well known. 2. debt equity ratio and promoter's share of total cost Existing investment by the promoter in any other business Projected cash flow and profitability Feasibility Study Process : 1. when it can be built. manufacturing. industrial. Cultural feasibility : In this stage. and to test alternative land uses for given parcels. 5. type and amount of resources required. dependencies. 3.
The latter builds upon the logic of cost-benefit analysis. it is also known as running the numbers. Preparing an economic analysis for each alternative that meets the established objectives and functional requirements. whether explicitly or implicitly. or how poorly. programme or policy proposal. but differs in that it is explicitly designed to inform the practical decision-making of enterprise managers and investors focused on optimizing their social and environmental impacts. weighing the total expected costs against the total expected benefits of one or more actions in order to choose the best or most profitable option. Selecting the alternative that is the best response to the problem or opportunity.6.‖ Closely related. The formal process is often referred to as either CBA (CostBenefit Analysis) or BCA (Benefit-Cost Analysis). Although a cost benefit analysis can be used for almost anything. so that all flows of benefits and flows of project costs over time (which tend to occur at different points in time) are expressed on a common basis in terms of their ―present value. or assess. A cost benefit analysis is done to determine how well. it is most commonly done on financial questions. Since the cost benefit analysis relies on the addition of positive factors and the subtraction of negative ones to determine a net result. There are four basic steps to performing a cost-benefit analysis: Identify the project or program and alternatives Describe quantitatively the inputs and outputs of each alternative Estimate the value of the costs and benefits Compare benefits and costs . economic impact analysis. Preparing a management plan for implementation of the proposed response. an approach to making economic decisions of any kind. 8. the case for a project. a planned action will turn out. Benefits and costs are often expressed in money terms. and are adjusted for the time value of money. 7. fiscal impact analysis and Social Return on Investment (SROI) analysis. Under both definitions the process involves. but slightly different. formal techniques include cost-effectiveness analysis. and 9. Documenting the results of the study in the form of a Feasibility Study Report (FSR). Cost Benefit Analysis : Cost benefit analysis is a term that refers both to: helping to appraise.
helping justify decisions at various levels Simplifies complex concepts and processes Accepted by society more readily than other economic methods Can be carried out at many levels (i.e.Identifying the costs and benefits. national. needs to consider factors such as environmental justice and indirect impacts Does not usually consider questions of environmental justice and how costs and benefits are distributed across different groups Process of Cost Benefit Analysis: 1.Identifying the preferred option 8.Performing sensitivity analysis and addressing issues of risk and uncertainty 7. both quantitative and qualitative 4. as well as indirect impacts Often requires nonmarket valuation methods with varying degrees of complexity and accuracy Costs are easier to estimate than benefits Can be a time-consuming and expensive process Does not always consider the source of the costs and benefits.Strengths and Limitations : Strengths Compares costs and benefits using equal terms Provides a clear indication of net cost or benefit of a specific area or regulation. international) Limitations Can be difficult to determine accurately the discount rate of future costs and benefits.Discounting the future costs and benefits 5.Calculating the decision criteria 6. annual reports and other relevant documents.. regional.Clarifying the proposal options 3.Preparing the report. Step 1: Define Objectives and Project Scope : 1 The Importance of Objectives Project identification and specification should be linked to CASA strategic objectives—eg. Consistency with stated Government policy vis-à-vis airspace management is an important . local.Defining the objectives and scope of the proposal/project 2. as indicated in ministerial policy statements.
as well as how this fits with Australia‘s international obligations and agreed standards. . The base case provides the benchmark against which the proposed project can be measured. whilst qualitative costs and benefits must be described and discussed as appropriate. When describing the options. passengers on commercial and other aircraft. It will be necessary to determine the feasible options. Identification of the likely ‗impacted parties‘ and the probable nature of such impacts is a typical example of the sort of questions dealt with well in a VM workshop at an early stage of the evaluation process. the analyst should include: _ A schedule for the project/proposal phase comprising a planning and development schedule _ The expected operational date of the option plus an operational schedule (eg. and operators of air traffic and related services. 2 Proposal/Project Specification _ How will it meet objectives? _ Will it involve new capital works/equipment acquisition? _ Will there be a need to replace existing facilities/assets? _ Will there be a need to upgrade or enhance existing facilities? _ What are the constraints? _ Who is likely to be effected and how might impacts manifest? Step 2: Identify Project Options : 1 Range of Options Options are prepared to fulfil project objectives.consideration. etc) and a replacement schedule (for individual system components) _ Type of equipment required if there are different levels of service to be considered _ Economic life of the key assets involved _ A transition schedule (if appropriate) _ Identification of who will be investing in the project (as well as to whom the ‗case‘ needs to be justified to). Step 3: Identify Costs and Benefits : All relevant costs and benefits must be included in the evaluation. The range of feasible options will vary with the nature of the problem. CBA cannot be conducted without a base case. It needs to be recognised that these can accrue to a wide range of parties and. ―Are there other ways to achieve the same outcome?‖ could be an important question to address. Tasks set at the strategic level may generate a wide range of options. variations in the design and operational concepts. Quantitative costs and benefits are to be included in the discounted cash flow analysis. could include some or all of the following: operators of commercial and GA aircraft. given the particular situation. route structure. Agreeing and defining the base case can be problematic and may benefit from use of a VM workshop (as well as some ‗internal‘ discussion with technical experts within the organisation proposing the change proposal/project). It will be important to determine whether there are there variations on one basic identified option eg. the military (as an operator of aircraft and as a significant user of airspace for training purposes). The key question initially will be: What is the base case? Proposal options are evaluated relative to a base case. airspace organisation and structure.
ie.1 Identify Quantitative Costs The nature of the particular proposal being evaluated may be such that there may be a number of project phases to consider. optimum routing. The stages of development and the years in which costs are to be incurred needs to be specified. R&D. user community consultation) as well as in the implementation and operating phases of the change proposal or other initiative. where possible. parts of the existing/current system need to operated and maintained during the transition period to a new system. 2 Identify Quantitative Benefits There may be a range of benefits to be estimated and. etc) _ Construction costs (incl. testing of various technologies and equipment applications. There may be costs incurred during a planning phase (eg. Reductions in fuel and simpler (more predictable) crew scheduling could result from a reduction in delays and these will accrue benefits to aircraft operators. Discounting satisfies the view that people prefer immediate benefits over future benefits . removal of redundant equipment/facilities. _ Incremental net revenue from changes in costs and charges. equipment or software) – typically one-off expenditures necessary for the project/proposal _ Land acquisition and land restitution costs (including demolition. site preparation. _ Residual values (should be included in the DCF analysis as a ‗negative‘ cost item). differences in operating and maintenance costs of equipment and aircraft). operating and maintenance costs associated with new technologies. quantified such as: _ Cost savings between options (eg. land clearance. _ Improvements to the ratio of transit time to training time for military operations (training sorties). There may be a number of capital and other cost components incurred over time that need to be included in the evaluation such as: _ Capital (or investment) items (eg. discounting is the reverse of adding (or compounding) interest. These may also include cost savings for aircraft operators due to a reduction in delays and reduced investment. Savings in operating costs such as reductions in fuel and oil costs and flight time related operating costs (primarily crew and parts of maintenance costs) are treated as benefits in CBA. professional fees) _ Upgrade or refurbishment costs _ Project management costs _ Decommissioning costs _ Transition costs eg. _ Asset disposal. It reduces the monetary value of future costs and benefits back to a common time dimension – the base year/date. Travel time benefits can also come from a reduction in aircraft delays. Step 4: Discount Future Costs and Benefits : 1 DCF Analysis Discounting – what is it and why do it? As noted earlier. _ User benefits such as travel timesavings for passengers that could accrue due to accommodating the optimum flight profile as desired by the operator. altitude and speed.
the NPV/i ratio facilitates capital rationing and indicates the highest return per dollar invested. In other words. In summary. . payback period) in the initial base evaluation. Step 5: Calculate the Decision Criteria : As noted previously. The ranking of options by NPV and NPV/i in the subsequent sensitivity tests. the identification of the preferred option requires: 1. they should be utilised only as supplementary indicators. using different assumptions for various variables. 2. the option with the highest NPV provides the best economic return. It recommended that at a minimum the NPV is calculated and that this should be the key decision criteria as this is considered to provide a better measure of society‘s wealth maximisation than. in an unconstrained market. Where there is a budget constraint however. 2 Discounting Parameters The analyst needs to determine the following when preparing to undertake the DCF aspects of CBA: _ The appropriate price year for cost estimates and the level of prevailing inflation _ Whether analysis of relative prices is necessary for some cost items (eg. It is therefore possible that an option may well result in a lower NPV but a higher NPV/i ratio than another option.(social time preference) and it also enables the opportunity cost to be reflected (opportunity cost of capital). for example. Step 7: Identify Preferred Option : All relevant results and issues must be considered when identifying the preferred option. IRR. Step 6: Sensitivity Analysis : Sensitivity analysis should be undertaken to test the robustness of results under different scenarios. The ranking of options by NPV and NPV/i and possibly BCR and IRR and other criteria (eg. BCR and payback period. This enables the economic worth of the options to be determined relative to the base case. all costs and benefits over the evaluation period are discounted to a present value to enable comparison between overall costs and benefits. It is a necessary part of any investment appraisal as it can: _ Test the impact of using different discount rates (the agreed rate should be used with sensitivity analysis two or three per cent points ‗above‘ and ‗below‘ the agreed rate) _ Assess the possible impact of uncertainty _ Illustrate what would happen if the assumptions made about some variables proved to be wrong and show how changes in the values of various factors affect the overall costs or benefit of a given project _ Indicate the critical elements on which the positive outcome of the project depends. the internal rate of return of benefit-cost ratio. While the other measures can be readily calculated eg. labour costs) _ What the base year (or discount year) is to be _ What is to be the base/initial evaluation discount rate _ The evaluation period (or project period).
a judgement between competing options will need to be made.a requirements specification for a software system . including the results and recommendations _ The background to the evaluation. This may require an assessment of whether the net intangible benefits of the second ranked options can be valued at the difference in NPV between it and the first ranked option. It is recommended to use NPV and NPVi for decision-making. when there are significant differences in intangibles between options. However. NVP/i and possibly BCR and IRR _ The results of any sensitivity tests including specific risk modelling/analyses _ A discussion of qualitative factors (costs and benefits). including NPV. the ranking of options in the sensitivity tests will usually reflect the ranking of the initial evaluation. The weighting of costs and benefits which have only been quantified in physical units or described in qualitative terms (‗intangibles‘) between options.is a complete description of the behavior of a system to be developed. Where a project is robust. including the key assumptions and inputs sourced from technical analysis undertaken to inform the CBA _ The annual cost and benefit streams _ The results of the evaluation. It includes a set of use cases that describe all the interactions the users will have with the software. 4. Software Requirements Specification: A Software Requirements Specification (SRS) . ranking given by the cost-benefit criteria are usually sufficient and undisputed. the ranking of options in the sensitivity tests may vary in comparison to the initial evaluation ranking in the case of less robust proposals/projects. The overall ranking of options based on steps (1) to (3). the SRS also contains non- . Use cases are also known as functional requirements. including ❍Reasons underpinning the proposal ❍A statement of why the initiative needs to be implemented immediately ❍ Implications of deferring implementation of the proposal/project ❍The proposal‘s/project‘s classification _ The objectives of the project/proposal _ Evaluation considerations ❍Strategic issues particular to this proposal which will influence both the choice of the options and the identification of appropriate costs and benefits _ A description of the options. In addition to use cases. even though this is inevitably subjective and somewhat arbitrary. When the unquantified and external costs and benefits are broadly similar in nature.3. However. This detailed report should include: _ An Executive Summary of the evaluation. including the base case _ The identification of all costs and benefits. Step 8: Prepare Report : Full Evaluation Report The final step of the CBA process is producing the report with the appraisal findings and recommendations.
and documentation plans. A software requirements specification (SRS) is a comprehensive description of the intended purpose and environment for software under development. and helps break down the problem into its component parts in an orderly fashion. solidifies ideas. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS also functions as a blueprint for completing a project with as little cost growth as possible.. The SRS is often referred to as the "parent" document because all subsequent project management documents. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. security and speed of recovery from adverse events are evaluated. The SRS document itself states in precise and explicit language those functions and capabilities a software system (i. places borders around the problem. decision tables.functional (or supplementary) requirements. testing and validation plans. tables. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements. possible solutions to technology or business issues. portability. software architecture specifications. 2. A good SRS defines how an application will interact with system hardware. statements of work. such as design specifications. footprint. a software application. or design constraints).e. an eCommerce Web site. A well-designed. data flow diagrams. explained later in this article). and so on) must provide. quality standards. availability. well-written SRS accomplishes four major goals: 1. . the SRS should be written in natural language (versus a formal language. and so on. An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. The SRS fully describes what the software will do and how it will be expected to perform. in an unambiguous manner that may also include charts. or any other information other than what the development team understands the customer's system requirements to be. Therefore. The simple act of writing down software requirements in a well-designed format organizes information.It decomposes the problem into component parts. as well as states any required constraints by which the system must abide. it doesn't offer design suggestions. Parameters such as operating speed. response time. other programs and human users in a wide variety of real-world situations. are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only. maintainability. An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost.It provides feedback to the customer.
The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.3. Reduce the development effort. Customers thus find it easier to transfer the software to other parts of their organization. The preparation of the SRS forces the various concerned groups in the customer‘s organization to consider rigorously all of the requirements before design begins and reduces later redesign. As mentioned previously. Therefore. but it does provide a foundation for continued production evaluation. misunderstandings. [NOTE: We use the SRS to create the Test Plan]. Serve as a basis for enhancement. the system‘s hardware. and inconsistencies early in the development cycle when these problems are easier to correct. Benefits of SRS: Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The SRS may need to be altered. the SRS serves as the parent document to subsequent documents. What is the software supposed to do? b) External interfaces. recoding. the SRS provides a baseline against which compliance can be measured. Because the SRS discusses the product but not the project that developed it. Organizations can develop their validation and Verification plans much more productively from a good SRS. serves as an input to the design specification. and suppliers find it easier to transfer it to new customers. Facilitate transfer.The SRS makes it easier to transfer the software product to new users or new machines. we use the SRS as the basis for our fixed price estimates] Provide a baseline for validation and verification.It serves as a product validation check. [NOTE: Again. As a part of the development contract. such as the software design specification and statement of work. [NOTE: This is often a major pitfall – when the SRS is not continually updated with changes] The basic issues that the SRS writer(s) shall address are the following: a) Functionality. and other software? . 4. How does the software interact with people. The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs. and retesting. the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. the SRS serves as a basis for later enhancement of the finished product. Careful review of the requirements in the SRS can reveal omissions. other hardware. [NOTE: We use it as the basis of our contract with our clients all the time]. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. Provide a basis for estimating costs and schedules.
Complete .Don't put in requirements like . every requirement stated therein has only one interpretation. If you call an input "Start and Stop" in one place. No one writes a specification that they know is incorrect. We like to say ." Instead.fix them. maintainability." The discipline is keeping the specification up to date when you find things that are not correct. Ranked for Importance . don't call it "Start/Stop" in another. It is useful provide this information in the SRS. easier said than done.? Characteristics of SRS: a) Correct b) Unambiguous c) Complete d) Consistent e) Ranked for importance and/or stability f) Verifiable g) Modifiable h) Traceable Correct .Very often a new system has requirements that are really marketing wish lists. What is the speed.but tends to make the document not maintainable.? d) Attributes. operating environment(s) etc. Unambiguous . Some may not be achievable." Modifiable .c) Performance."It should provide the user a fast response. implementation language. recovery time of various software functions. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities . resource limits."Correct and Ever Correcting. policies for database integrity. Are there any required standards in effect. provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds. considerations? e) Design constraints imposed on an implementation.Having the same requirement in more than one place may not be wrong . etc. Again."The system should never crash.An SRS is unambiguous if. Of course you want the specification to be correct. security. correctness. Verifiable ." Another of my favorites is .The SRS should be consistent within itself and consistent to its reference documents. . etc. Consistent .A simple judge of this is that is should be all that is needed by the software designers to create the software.This is like motherhood and apple pie. What are the portability. response time. availability. and only if.
Use cases would consist of creating a new order.Often.Define the performance specification.Traceable . For example.Define the user interface. 3. 9. modifying an existing order. customer order search. etc. this is not important in a non-politicized environment. Why do we need this requirement? How to write a SRS: 1.Define the functions of the software. 8.Create any diagrams needed to illustrate process flow or elaborate on key requirements. How to Write a Software Requirements Specifications (SRS) Document By eHow Contributor . 2011 .Define any other interfaces such as hardware interfaces or other software system interfaces.Compile the SRS document and have all necessary parties review or sign off on it. 7. it is sometimes useful to connect the requirements in the SRS to a higher level document. 10. 5. 2. if you are designing an order entry system. 6. create one now. Please see the Resources section below for some links to templates I found on the internet. 4.If your organization does not have a standard Software Requirements Specifications document template.Meet with the subject matter experts / clients to gather the requirements. 11. However.Create use cases for the major sub processes. in most organizations.Determine any specific business rules. last updated August 01.Define the process flow.
For example. o Meet with the subject matter experts/clients to gather the requirements. o 5 . or SRS. use cases would consist of creating a new order. Usually the client reviews and signs the SRS. modifying an existing order and a customer order search. The end product of that project phase is a document commonly referred to as a Software Requirements Specification. if you're designing an order entry system. It's usually the first project milestone or deliverable. Once these requirements are compiled. the document becomes the record of both the client's and developer's understanding of what the software should accomplish. thus beginning the full software design and development phase.Software Requirements . By taking the high level steps involved. o Create use cases for the major sub-processes. create one now (see Resources for links to templates). you can write an SRS document. Its foremost function is to record the client's business needs and requirements in written form and become the foundation for the rest of the software development process. The importance of this document cannot be understated.SRS Professional software developers must go through a software requirements gathering process at the beginning of software development projects of any meaningful size. o Define the functions of the software. 1. o 1 2 3 4 If your organization does not have a standard Software Requirements Specifications document template.
o Define the performance specification.Define the user interface. o Compile the SRS document and have all necessary parties review or sign it . o 7 8 9 Define the process flow. o 10 11 Create any diagrams needed to illustrate the process flow or elaborate on key requirements. o Determine any specific business rules. o 6 Define any other interfaces such as hardware interfaces or other software system interfaces.