We have seen the positive benefits of SRS in previous section. Let us look at a scenario wherein the SRS is not properly defined and its impact on the project. This will enable us to understand the importance of SRS on the project:
• Impact on cost and schedule: Without a complete and accurate SRS, it would be difficult to properly estimate and plan the overall cost of the project. This would have ripple’ effect on resource staffing, milestone planning and overall project budget. As a result the entire project schedule, will be in jeopardy.
• Quality Impact: Incomplete requirements specification would manifest itself into incomplete test plan and impacts the quality of all project deliverables. This negatively impacts the project by re-testing, re-coding and re-design efforts leading to cost and effort overruns.
• Impact on overall customer/user satisfaction: An improperly translated user requirements would damage the customer confidence on the software product and reduces the usability ilrrd overall satisfaction index.
• Impact on maintenance: Without proper traceability, it would be difficult to extend the software, enhance it and to fix the issues. ‘
• Correct: SRS should specify the functionality correctly from all aspects. It
also be continually updated to reflect all the software updates and enhancements.
• Unambiguous: As SRS is written iri natural language, it is possible for it to be interpreted in multiple ways based on the context, cultural background etc. So, SRS should consider these things and define and refine in most unambiguous fashion as possible. This would include providing references, elaborating any abstract requirement with example scenarios etc. It is a good practice to get a proof read of SRS by another person to weed out an)' ambiguous descriptions.
• Precise: The description should not contain fizzy words so as to make it precise.
• Complete: SRS should provide all the details required by software .designers for design and implementation of the intended software.
• Consistent: The terminologies, definitions and others used throughout the SRS should be consistent. It is a good practice to pre-define all definitions, abbreviations and refer them consistently throughout SRS.
• Verifiable: This supplements the unambiguous characteristic. All requirements should be quantified with exact and verifiable numbers. For instance "The home page should load quickly" is non-verifiable as "quickly" is subjective; it is also not mentioned if the page should load quickly across all geographies. Instead of these subjective terms the requirement should quantify it with the exact response time: "The home page should load within 2 seconds in North America region".
• Modifiable: The requirements should be detailed only once throughout the document so that it is easy to modify and maintain the document in long run. To ensure that SRS is modifiable it should: 1. Be coherent, well-organized and contain cross-referencing 2. Avoid redundancy 3. State each requirement separately
• Traceable: SRS should map the requirements to other business/user requirement documents so that it is possible to trace the requirements. It should also support backward-traceability and forward traceability.
• Ranked for importance/stability: The requirements should be ranked based on its deemed business/user importance. Ranking is done based on: 1. Degree of stability: Stability is related to number of changes required for implementing functionality. 2. Degree of importance: In this case, the requirements are classified into categories such as essential, conditional and optional.
Few other characteristics of a good SRS are that it should be understandable by people of varied backgrounds and it should be design independent. That is, without favoring any particular design.
• Functionality: Complete details of the software.
• External Interfaces: Details of how the software interacts with external systems, and end users.
• Performance: Provides details of transaction speed, software availability, response time, failover conditions, disaster recovery scenarios, etc.
• Attributes: Provides details about portability, correctness, maintainability, security, extensibility, flexibility, etc.
• Constraints: All applicable architecture and design constraints including the maximum load supported, supported browsers, JavaScript dependency and others should be detailed.
• Forms the basis of agreement between customers and suppliers about ,
the software functionality: SRS serves as a structured contract between these parties specifying all functionalities along with constraints and mentions the behavior of the intended software. End user/customer can verify if the intended software meets all the needs and requirements stated in user requirements document.
• Optimizes development effort: As the requirements are fully specified beforehand, the implementation team can design the system accurately thereby reducing the effort in re-design, re-work, re-testing and defect fixing.
• Forms basis for cost and schedule estimation: Using the functional and' non-functional requirements specified in SRS, the project management team can estimate the overall project cost and schedule in more accurate fashion and make informed decisions about risk identification and mitigation.
• Forms basis for verification and validation: Quality team can design the validation and testing strategy including various kinds of test cases based on the requirements specified in SRS.
• Helps software portability and installation: The software usability information contained in SRS helps to transfer the software across various locations including multiple inter-company departments and other external customers.
• Helps in enhancement: As SRS specifies each requirement in fullest details, it would be easier to assess the impact of any enhancement planned providing the cost and schedule estimate of the enhancement
Components of ERD
Entities : An entity is something about which the business needs to store data. An entity is a class of persons, places, objects, events or concepts about which we need to capture and store data. An entity instance is a single occurrence of an entity.
Attribute: An attribute is a descriptive property or characteristic of an entity. Synonyms include element, property and field. A compound attribute is one that actually consists of other attributes. It is also known as a composite attribute. An attribute “Address” is the example of compound attribute as shown in the following illustration
Relationships: A relationship is a natural business association that exists between one or more entities. The relationship may represent an event that links the entities.
Cardinality: defines the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity. Because all relationships are bidirectional, cardinality must be defined in both directions for every relationship.
A DFD can be categorized in the following forms:ny system can be represented at any level of detail by these four symbols.
External Entities
External entities determine the system boundary. They are external to the system being studied. They are often beyond the area of influence of the developer.These can represent another system or subsystem. These go on margins/edges of data flow diagram. External entities are named with appropriate name.
Processes
Processes are work or actions performed on incoming data flows to produce outgoing data flows. These show data transformation or change. Data coming into a process must be “worked on” or transformed in some way. Thus, all processes must have inputs and outputs. In some (rare) cases, data inputs or outputs will only be shown at more detailed levels of the diagrams. Each process in always “running” and ready to accept data.Major functions of processes are computations and making decisions. Each process may have dramatically different timing: yearly, weekly, daily.
Naming Processes
Processes are named with one carefully chosen verb and an object of the verb. There is no subject. Name is not to include the word “process”. Each process should represent one function or action. If there is an “and” in the name, you likely have more than one function (and process). For example, get invoice ,update customer and create Order Processes are numbered within the diagram as convenient. Levels of detail are shown by decimal notation. For example, top level process would be Process 14, next level of detail Processes 14.1-14.4, and next level with Processes 14.3.1-14.3.6. Processes should generally move from top to bottom and left to right.
Data Flow
Data flow represents the input (or output) of data to (or from) a process (“data in motion”). Data flows only data, not control. Represent the minimum essential data the process needs. Using only the minimum essential data reduces the dependence between processes. Data flows must begin and/or end at a process.Data flows are always named. Name is not to include the word “data”. Should be given unique names. Names should be some identifying noun. For example, order, payment, complaint.
Data Stores
or
Data Stores are repository for data that are temporarily or permanently recorded within the system. It is an “inventory” of data. These are common link between data and process models. Only processes may connect with data stores.There can be two or more systems that share a data store. This can occur in the case of one system updating the data store, while the other system only accesses the data. Context diagrams An overview of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system. In this diagram, a single process represents the whole system.
First level DFD: A data flow diagram that represents a system’s major processes, data flows, and data stores at a high level of detail.
CSS handles the look and feel part of a web page. Using CSS the color of the text, the style of fonts, the spacing between paragraphs, how columns are sized and laid out, what background images or colors are used, layout designs, variations in display for different devices and screen sizes as well as a variety of other effects. CSS provides powerful control over the presentation of an HTML document. Most commonly, CSS is combined with the markup languages HTML or XHTML.
You can define a style for each HTML element and apply it to as many Web pages as you want.
You do not need to write HTML tag attributes every time. Just write one CSS rule of a tag and apply it to all the occurrences of that tag.
CSS simply change the style, and all elements in all the web pages will be updated automatically.
CSS using the same HTML document, different versions of a website can be presented for handheld devices such as PDAs and cell phones or for printing.
Its a good idea to start using CSS in all the HTML pages to make them compatible to future browsers.
Java is an object-oriented programming language, we have to follow the encapsulation wherein we hide the unwanted details.
Java provides entities called “Access Modifiers or access specifiers” that help us to restrict the scope or visibility of a package, class, constructor, methods, variables, or other data members. These access modifiers are also called “Visibility Specifiers”.
Access Modifiers In Java To ensure encapsulation and reusability, these access specifiers/modifiers are an integral part of object-oriented programming.
Modifiers in Java are of two types:
#1) Access Modifiers
Access modifiers in Java allow us to set the scope or accessibility or visibility of a data member be it a field, constructor, class, or method.
#2) Non-access Modifiers
Java also provides non-access specifiers that are used with classes, variables, methods, constructors, etc. The non-access specifiers/modifiers define the behavior of the entities to the JVM.
Some of the non-access specifiers/modifiers in Java are:
static
final
abstract
transient
volatile
synchronized
native
Types Of Access Modifiers In Java
Java provides four types of access specifiers that we can use with classes and other entities.
These are:
#1) Default: Whenever a specific access level is not specified, then it is assumed to be ‘default’. The scope of the default level is within the package.
#2) Public: This is the most common access level and whenever the public access specifier is used with an entity, that particular entity is accessible throughout from within or outside the class, within or outside the package, etc.
#3) Protected: The protected access level has a scope that is within the package. A protected entity is also accessible outside the package through inherited class or child class.
#4) Private: When an entity is private, then this entity cannot be accessed outside the class. A private entity can only be accessible from within the class
