When inputs from multiple people are to be gathered, these inputs are likely to be inconsistent. The process of specifying requirements can’t be totally formal; any formal translation process producing a formal output must have a precise and unambiguous input. That is why the s/w requirements activity can’t be fully automated, and any method for identifying requirements can be at best a set of guidelines.
Generally, the SRS is a document that completely describes what the proposed s/w should do without describing how the s/w will do it. The SRS describes the complete external behavior of the proposed s/w. However, producing the SRS is easier said than done. A basic limitation for this is that the user needs keep changing as the environment in which the system was function changes with time. The problem gets worse because the SRS and the process of requirements analysis and specification give additional ideas to clients about what is needed from the system.
Even while accepting that some requirement change requests are unavoidable, there are still pressing reasons to produce a high-quality and relatively stable SRS.
Need (Importance) for SRS
A basic purpose of SRS is to bridge the communication gap between client and developer. An SRS is the medium through which the client and user needs are accurately specified. A good SRS should satisfy all the parties—something very hard to achieve—and involves trade-offs and persuasion (convincing).
Another important purpose of developing an SRS is helping the clients understand their own needs. For s/w systems that are not just automating existing manual systems, requirements have to be visualized and created. New requirements emerge (come out) as the introduction of a software system offers new potential for features, such as providing new services, performing activities in a different manner, and collecting data, that were either impossible or infeasible without a software system. In order to satisfy the client, (which is the basic quality objective of software development) the client has to be made aware of these potentials and aided in visualizing and conceptualizing the needs and requirements. The process of developing an SRS usually helps in this, as it forces the client and the users to think, visualize, interact, and discuss with others (including the requirement analyst) to identify the requirements.
- An SRS establishes the basis for agreement between the client and the supplier on what the software product will do.
- This basis for agreement is frequently formalized into a legal contract between the client and the developer (the supplier). So, through SRS, the client clearly describes what it expects from the supplier, and the developer clearly understands what capabilities to build in the s/w. Without such an agreement, it is almost guaranteed that once the development is over, the project will have an unhappy client, which almost always leads to unhappy developers. (The classic situation is, client: “Hey! there is a bug”; Developer: “No, it is a software feature.”) Actually, the reality of the situation is that even with such an agreement, the client is frequently not satisfied!
- An SRS provides a reference for validation of the final product.
- The SRS helps the client to determine if the software meets all the requirements. Without a proper SRS, there is no way a client can determine if the software being delivered is what was ordered, and there is no way the developer can convince the client that all the requirements have been fulfilled.
- Point : The primary forces that driving a project are cost, schedule, and quality.
- A high-quality SRS is a prerequisite (necessary) to high-quality software.
- If the SRS specifies a wrong system (i.e., one that will not satisfy the client’s objectives), then even a correct implementation of the SRS will lead to a system that will not satisfy the client. Clearly, if we want high-quality final software that has few errors, we must begin with a high-quality SRS.
- A high-quality SRS reduces the development cost.
- The quality of SRS has an impact on cost (and schedule) of the project. The errors can be in the SRS. The cost of fixing an error increases almost exponentially as time progresses. That is, a requirement error, if detected and removed after the system has been developed can cost up to 100 times more than removing it during the requirements phase itself. We can have a tremendous reduction in the project cost by reducing/removing the errors in the SRS and spend the extra effort in the Req. phase.
- We assume that the average cost of fixing a requirement error in the requirement phase is about 2 person-hours. From this and the relative cost of fixing errors as reported in a multicompany study, the approximate average cost of fixing requirement errors depending on the phase is shown in the Table.
|Operaton & Main.||150|
General distribution was found for the requirements errors that remain after the requirements phase, about 65%are detected during design, 2% during coding, 30% during testing, and 3% during operation and maintenance.
With a high-quality SRS, requirement changes that come about due to improperly analyzed requirements should be reduced considerably. A reduction in the requirement change traffic will reduce the project cost, in addition to improving its chances of finishing project on schedule.
Hence the quality of the SRS impacts customer (and developer) satisfaction, system validation, quality of the software, and the software development cost. One will assume that these reasons will ensure that every software project has a high-quality SRS as its starting point. Unfortunately, that is not common practice in the industry. Due to lack of understanding of the role and importance of SRS, and in an effort to “speed up” development and ‘‘cut costs” by eliminating “nonessential” activities (which frequently means anything other than coding) many software projects start with a low-quality SRS that is incomplete and full of ambiguities. The results are, most of the projects have cost and schedule overruns (rather than reducing cost and time, as is the intention) and the software industry has developed a reputation of providing poor-quality products.
The final output of Requirement Analysis phase is the Software Requirements Specification document (SRS). For smaller problems or problems that can easily be understood, the specification activity might come after the entire analysis is complete. However, it is more likely that problem analysis and specification are done concurrently. In practice, problem analysis and requirements specification activities overlap, with movement from both activities to the other, as shown in the figure. The primary objective of analysis is problem understanding, while the basic objective of the requirements phase is to produce the SRS.
Characteristics of an SRS:-
An SRS should contain different types of requirements. A good SRS is :
- Ranked for importance and/or stability
1 & 2) An SRS is correct if every requirement included in the SRS represents something required in the final system. An SRS is complete if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. Correctness and completeness go hand-in-hand; whereas correctness ensures that what is specified is done correctly, completeness ensures that everything is indeed specified.
Correctness is an easier property to establish than completeness as it basically involves examining each requirement to make sure it represents the user requirement. Completeness, on the other hand, is the most difficult property to establish; to ensure completeness, one has to detect the absence of specifications, and absence is much harder to ascertain (determine) than determining that what is present has some property (effects).
3) An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language, which are inherently (essentially) ambiguous. E.g. A requirement like “User contact information is mandatory.” is ambiguous. If the requirements are specified in a natural language, the SRS writer has to be especially careful to ensure that there are no ambiguities. One way to avoid ambiguities is to use some formal requirements specification language. The major disadvantage of using formal languages is the large effort required to write an SRS, the high cost of doing so and it increased difficulty in reading and understanding (formally stated requirements) (particularly by the users and clients).
4) An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement. This implies that the requirements should have as little subjectivity as possible because subjective requirements are difficult to verify. Unambiguity is essential for verifiability. As verification of requirements is often done through reviews, it also implies that an SRS is understandable, at least by the developer, the client, and the users. Understandability is extremely important, as one of the goals of the requirements phase is to produce a document on which the client, the users, and the developers can agree.
5) An SRS is consistent if there is no requirement that conflicts with another. Terminology can cause inconsistencies; for example, different requirements may use different terms to refer to the same object. There may be logical or temporal conflict between requirements causing inconsistencies. E.g. suppose a requirement states that an event e is to occur before another event f. But then another set of requirements states (directly or indirectly) that event f should occur before event e. Inconsistencies in an SRS can be a reflection of some major problems.
6) Generally, all the requirements for software are not of equal importance. Some are critical, others are important but not critical, and there are some, which are desirable, but not very important. Similarly, some requirements are “core” requirements, which are not likely to change as time passes, while others are more dependent on time. An SRS is ranked for importance and/or stability if for each requirement the importance and the stability of the requirement are indicated. Stability of a requirement reflects the chances of it changing in future.
7) Writing an SRS is an iterative process. Even when the requirements of a system are specified, they are later modified as the needs of the client change. Hence an SRS should be easy to modify. An SRS is modifiable if its structure and style are such that any necessary change can be made easily while preserving completeness and consistency. Presence of redundancy is a major hindrance (stoppage) to modifiability, as it can easily lead to errors. For example, assume that a requirement is stated in two places and that the requirement later needs to be changed. If only one occurrence of the requirement is modified, the resulting SRS will be inconsistent.
8) An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in, future development. Forward traceability means that each requirement should be traceable to some design and code elements. Backward traceability requires that it be possible to trace design and code elements to the requirements they support. Traceability aids verification and validation.
Of all these characteristics, completeness is perhaps the most important (and hardest to ensure). One of the most common problems in requirements specification is when some of the requirements of the client are not specified. This necessitates additions and modifications to the requirements later in the development cycle, which are often expensive to incorporate. The importance of having complete requirements cannot be overemphasized.
Components of an SRS :
The following are the system properties (components) that an SRS should specify.
3) Design constraints imposed (dictated) on an implementation
4) External interfaces
1) Functional Requirements:-
Functional requirements specify which outputs should be produced from the given inputs. For each functional requirement, a detailed description of all the input data, their source, the units of measure and the range of valid inputs must be specified.
All the operations to be performed on the input data to obtain the output should be specified. This includes specifying the validity checks on the input and output data, parameters affected by the operation, and equations or other logical operations that must be used to transform the inputs into corresponding outputs. E.g. any formula for computing the output.
An important part of the specification is the system behavior in abnormal situations, like invalid input or error during computation. The Functional requirements must clearly state, what the system should do in abnormal situations like invalid input. Specifically, it should specify the behavior of the system for invalid inputs & invalid outputs. Furthermore, behavior for situations where the input is valid but the normal operation can’t be performed should also be specified. E.g. An Airlines Reservation System, where a reservation cannot be made even for valid passengers if the airplane is fully booked. In short, the system behavior for all foreseen (expected) inputs and all foreseen states should be specified. These special conditions are often likely to be overlooked (neglected, forgotten).
2) Performance Requirements:-
This part specifies the performance constraints. There are two types of Performance requirements: Static and Dynamic.
1) Static: Static Requirements are those that do not impose constraint on the execution characteristics of the system. These include requirements like the number of terminals to be supported, the number of simultaneous users to be supported, and the number of files that the system has to process and their sizes. These are also called ‘Capacity’ requirements of the system.
2) Dynamic: They specify constraints on the execution behavior of the system. These typically include response time and throughput constraints on the system. Response time is the expected time for the completion of an operation under specified circumstances. Throughput is the expected number of operations that can be performed in a unit time. E.g. the SRS may specify the number of transactions that must be processed per unit time or what response time for a particular command should be. Acceptable ranges of the different performance parameters should be specified, as well as acceptable performance for both normal and peak workload conditions.
All of these requirements should be stated in measurable terms. Requirements such as “response time should be good” or the system must be able to “process all the transactions quickly” are not desirable because they are imprecise and not verifiable. Instead, statements like “the response time of command x should be less than one second 90% of the times” or “a transaction should be processed in less than one second 98% of the times” should be used to declare performance specifications.
3) Design Constraints :
There are number of factors in the client’s environment that may restrict the choices of a designer. Such factors include standards that must be followed, resource limits, operating environment, reliability and security requirements, and policies that may have an impact on the design of the system. An SRS should identify and specify all such constraints.
1) Standards Compliance (agreement): This specifies the standards that your system must follow. e.g. Report format, Accounting procedures etc. There may be audit tracing requirements, which require certain kinds of changes, or operations that must be recorded in an audit file.
2) Hardware Limitations: The software may have to operate on some existing or predetermined (prearranged) hardware, thus imposing restrictions on the design. These can include the type of machines to be used, Operating System available on the system, Language supported & limits on primary & secondary storage.
3) Reliability & Fault Tolerance (Stamina): Fault tolerance requirements can place a major constraint on how the system is to be designed. It often makes the system more complex and expensive. Requirements about system behavior in the appearance (face) of certain kinds of faults are specified. Recovery requirements specify what the system should do if some failure occurs. Reliability requirements are very important for critical applications.
4) Security: Security requirements are particularly significant in defense systems and many database systems. These requirements place restrictions on the use of certain commands, control access to data, provide different kinds of access requirements for different people, require the use of passwords, cryptography techniques and maintain a log of activities in the system.
4) External Interface Requirements:
All the possible interactions of the software with people, hardware & other software should be clearly specified.
People: The characteristics of each user interface to the software should be specified. A preliminary user manual should be created with all user commands, screen formats, an explanation of how the system will appear to the user, error messages. So, the statements like “The system should be user friendly” should be avoided and “Commands should be no longer than 4 characters” OR “Command names should reflect the function they perform” used.
Hardware: For hardware interface requirements, the SRS should specify the logical characteristics of each interface between the software product and the hardware components. If the software is to execute on existing hardware or on predetermined hardware, all the characteristics of the hardware, including memory restrictions, should be specified. In addition, the current use and load characteristics of the hardware should be given.
Software: The interface requirement should specify the interface with other software the system will use or that will use by the other system. This includes the interface with the operating system and other applications. The message content and format of each interface should be specified.
STRUCTURE OF SRS
- Definitions, Acronyms and abbreviations
- Overall Description
- Product Perspective
- Product Functions
- User Characteristics
- General Constraints
- Assumptions and Dependencies
- Specific Requirements
- External Interface Requirements
- User interfaces
- Hardware interfaces
- Software Interfaces
- Communication Interfaces
- External Interface Requirements
- Functional Requirements
- Mode I
- Functional Requirement
- Functional Requirement
- Mode I
- Mode M
- Functional Requirement m.1
- Functional Requirement m.n
- Performance Requirements
- Design Constraints
- Other Requirements
The objectives of a feasibility study are to find out if an information system project can be done (…is it possible?…is it justified?) and to suggest possible alternative solutions.
A feasibility study should provide management with enough information to decide:
- whether the project can be done
- whether the final product will benefit its intended users
- what are the alternatives among which a solution will be chosen (during subsequent phases)
- is there a preferred alternative
After a feasibility study, management makes a go/no go decision
The feasibility study is a management-oriented activity
What to Study? …What to Conclude?
- Things to be studied during the feasibility study phase:
- The present organizational system, including users, policies, functions, objectives,…Problems with the present system (inconsistencies, inadequacies in functionality, performance,…,Objectives and other requirements for the new system (what needs to change?)
Constraints, including nonfunctional requirements on the system possible alternatives (the current system is always one of those)
Advantages and disadvantages of the alternatives
Things to conclude: Feasibility of the project and the preferred alternative.
Types of Feasibility
Operational — Define the urgency of the problem and the acceptability of any solution; if the system is developed, will it be used? Includes people-oriented and social issues: internal issues, such as manpower problems, labour objections, manager resistance, organizational conflicts and policies; also external issues, including social acceptability, legal aspects and government regulations.
Technical — Is the project feasibility within the limits of current technology? Does the technology exist at all? Is it available within given resource constraints (i.e., budget, schedule,…)?
Economic (Cost/Benefits Analysis) — Is the project possible, given resource constraints? Are the benefits that will accrue from the new system worth the costs? What are the savings that will result from the system, including tangible and intangible ones? What are the development and operational costs?
Schedule — Constraints on the project schedule and whether they could be reasonably met
Constraints may be hard or soft
- Performance — Does current mode of operation provide adequate throughput and response time?
- Information — Does current mode provide end users and managers with timely, pertinent, accurate and usefully formatted information?
- Economy — Does current mode of operation provide cost-effective information services to the business? Could there be a reduction in costs and/or an increase in benefits?
- Control — Does current mode of operation offer effective controls to protect against fraud and to guarantee accuracy and security of data and information?
- Efficiency — Does current mode of operation make maximum use of available resources, including people, time, flow of forms…
- Services — Does current mode of operation provide reliable service? Is it flexible and expandable?
More on Operational Feasibility:
Acceptability of Potential Solutions
How do end-users and managers feel about the problem (solution)?
It’s not only important to evaluate whether a system can work but also evaluate whether a system will work.
- A workable solution might fail because of end-user or management resistance.
- Does management support the project?
- How do the end-users feel about their role in the new system?
- What end-users or managers may resist or not use the system?
- People tend to resist change. Can this problem be overcome? If so, how?
- How will the working environment of the end-users change?
- Can or will end-users and management adapt to the change?
Is the proposed technology or solution practical?
Do we currently possess the necessary technology?
Do we possess the necessary technical expertise, and is the schedule reasonable?
The technology for any defined solution is usually available;
However, the question is whether that technology is mature enough to be easily applied to our problem. Some firms like to use state-of-the-art technology, but most firms prefer to use mature and proven technology.
A mature technology has a larger customer base for obtaining advice concerning problems and improvements. Assuming that required technology is practical, is it available in the information systems shop? If the technology is available, does it have the capacity to handle the solution?
If the technology is not available, can it be acquired?
We may have the technology, but that doesn’t mean we have the skills required to properly apply that technology; True, all information systems professionals can learn new technologies; However, that learning curve will impact the technical feasibility of the project; specifically, it will impact the schedule.
Given our technical expertise, are the project deadlines reasonable?
Some projects are initiated with specific deadlines; one needs to determine whether the deadlines are mandatory or desirable. If the deadlines are desirable rather than mandatory, the analyst can propose alternative schedules.
It is preferable (unless the deadline is absolutely mandatory) to deliver a properly functioning information system two months late than to deliver an error-prone, useless information system on time!
Missed schedules are bad, but inadequate systems are worse!
The bottom line in many projects is economic feasibility.
During the early phases of the project, economic feasibility analysis amounts to little more than judging whether the possible benefits of solving the problem are worthwhile.
As soon as specific requirements and solutions have been identified, the analyst can weigh the costs and benefits of each alternative.
This is called a cost-benefit analysis.
The purpose of a cost/benefit analysis is to answer questions such as:
- Is the project justified (because benefits outweigh costs)?
- Can the project be done, within given cost constraints?
- What is the minimal cost to attain a certain system?
- What is the preferred alternative, among candidate solutions?
- Examples of things to consider:
- Hardware/software selection
- How to convince management to develop the new system
- Selection among alternative financing arrangements (rent/lease/purchase)
Difficulties — discovering and assessing benefits and costs; they can both be intangible, hidden and/or hard to estimate, it’s also hard to rank multi-criteria alternatives
Types of Benefits
Cost reductions, error reductions, increased throughput, increased flexibility of operation, improved operation, better (e.g., more accurate) and more timely information.
Benefits may be classified into one of the following categories:
Monetary — when $-values can be calculated
Tangible (Quantified) — when benefits can be quantified, but $- values can’t be calculated
Intangible — when neither of the above applies
Types of Costs
- Project-related costs Development and purchasing costs: who builds the system (internally or contracted out)? Software used (buy or build)? Hardware (what to buy, buy/lease)? Facilities (site, communications, power,…)
- Installation and conversion costs: installing the system, training of personnel, file conversion,…. Operational costs (on-going) Maintenance: hardware (maintenance, lease, materials,…),software (maintenance fees and contracts), facilities Personnel: operation, maintenance
For a small business that wants to introduce a PC-based information system, these cost categories translate to the following:
- Project costs: purchasing (hardware, software, office furniture),customizing software, training, system installation and file conversion
- On-going costs: operating the system (data entry, backups, helping users, vendors etc.), maintenance (software) and user support, hardware and software maintenance, supplies
Role of System Analyst
The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.
Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following
It includes system’s study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.
System analysis and design
Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.
Systems analysis, design, and programming
Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.
Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.
- Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses.
- Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them
- Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.
- The analyst’s primary focus is on “what,” not “how.” What data does the system produce and consume, what functions must the system perform, what behaviors does the system exhibit, what interfaces are defined and what constraints apply.
- Analyst creates models of the system in an effort to better understand data and control flow, functional processing, operational behavior, and information content. The model serves as a foundation for software design and as the basis for the creation of specifications for the software.
- The analyst must define all externally observable data objects, evaluate the flow and content of information, define and elaborate all software functions, understand software behavior in the context of events that affect the system, establish system consequence of requirements analysis.
Quality Function Deployment
- Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software.
- QFD “concentrates on maximizing customer satisfaction from the software engineering process.” To accomplish this, QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.
- QFD defines requirements in a way that maximizes customer satisfaction.
QFD identifies three types of requirements:
Normal requirements: The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present, the customer is satisfied. Examples of normal requirements might be requested types of graphical displays, specific system functions, and defined levels of performance.
Expected requirements: These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction.
Examples of expected requirements are: ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation.
Exciting requirements: These features go beyond the customer’s expectations and prove to be very satisfying when present. For example, word processing software is requested with standard features. The delivered product contains a number of page layout capabilities that are quite pleasing and unexpected.
In actuality, QFD spans the entire engineering process. However, many QFD concepts are applicable to the requirements elicitation activity.
In meetings with the customer, function deployment is used to determine the value of each function that is required for the system.
Information deployment identifies both the data objects and events that the system must consume and produce. These are tied to the functions.
Finally, task deployment examines the behavior of the system or product within the context of its environment. Value analysis is conducted to determine the relative priority of requirements determined during each of the three deployments.
QFD uses customer interviews and observation, surveys, and examination of historical data as raw data for the requirements gathering activity. These data are then translated into a table of requirements — called the customer voice table — that is reviewed with the customer.
A variety of diagrams, matrices, and evaluation methods are then used to extract expected requirements and to attempt to derive exciting requirements.
Note: often the exciting requirements lead to a breakthrough product!
1. The information domain of a problem must be represented and understood.
2. The functions that the software is to perform must be defined.
3. The behavior of the software (as a consequence of external events) must be represented.
4. The models that depict information function and behavior must be partitioned in a manner that uncovers detail in a layered fashion.
5. The analysis process should move from essential information toward implementation detail.
- By applying these principles, the analyst approaches a problem systematically. The information domain is examined so that function may be understood more completely.
- Models are used so that the characteristics of function and behavior can be communicated in a compact fashion.
- Partitioning is applied to reduce complexity.
- Essential and implementation views of the software are necessary to accommodate the logical constraints imposed by processing requirements and the physical constraints imposed by other system elements.
Guiding principles for requirements engineering:
- Understand the problem before you begin to create the analysis model
- Develop prototypes that enable a user to understand how human/machine interaction will occur.
- Record the origin of and the reason for every requirement.
- Use multiple views of requirements.
- Rank requirements.
- Work toeliminate ambiguity
Requirements are represented in a manner that ultimately leads to successful software implementation. A number of specification principles, adapted from the work of Balzer and Goodman can be proposed:
1. Separate functionality from implementation.
2. Develop a model of the desired behavior of a system that encompasses data and the functional responses of a system to various stimuli from the environment.
3. Establish the context in which software operates by specifying the manner in which other system components interact with software.
4. Define the environment in which the system operates and indicate how “a highly intertwined collection of agents react to stimuli in the environment (changes to objects) produced by those agents”.
5. Create a cognitive model rather than a design or implementation model. The cognitive model describes a system as perceived by its user community.
6. Recognize that “the specifications must be tolerant of incompleteness and augmentable.” A specification is always a model—an abstraction—of some real (or envisioned) situation that is normally quite complex. Hence, it will be incomplete and will exist at many levels of detail.
7. Establish the content and structure of a specification in a way that will enable it to be amenable to change.
This list of basic specification principles provides a basis for representing software requirements. However, principles must be translated into realization.