2. Software engineering practices and requirement engineering Marks: 16

s/w engineering practices:-

o It is a collection of principles concepts methods and tools that s/w engineer uses daily.

o It allows the manager to manage the projects and engineers to build the programs.

o Definition:-

“S/w engineering practice is broad array of principles, concepts, methods, approaches and tools, which are used for

planning and developing the software.”

o S/w engineering is system process of developing the s/w.

o Importance:-

Practice helps to understand the concepts and principles that must be understood and followed for development of

the s/w.

Practice is what you do day in and day out.

o Essence of practice :-

George polya listed the following essence:-

1. Understand the problem :-

For understanding the problem following questions are asked :-

a. Who has stake in the solution to problem? i.e who are stake holders ?

b. Can the problem be compartmentalized?

c. What are unknowns? What data, functions are required to solve the problem?

d. Can problem be represented graphically? can analysis model be created.

2. Plan the solution:-

a. Has a similar problem been solved?

b. Is there existing s/w that implements the data functions features that are required?

c. Can you represent solution in effective manner? Can design model be created?

d. Can sub problems be defined?

3. Follow the plan :-

a. Is each component part of design correct? Has the design & code been reviewed? Have correct algorithm?

b. Does solution confirm to the plan?

4. Examine the result :-

a. Does solution produce results that conform to functions, data & features that are required?

b. Has the software been validated against all stakeholder requirements?

c. Is it possible to test each component part of the solution?

Core principles of s/w engineering:-o Principle is defined as, “an important assumption required in system of thought”.o Some principle focuses on s/w engineering as a while & other specific framework activity, actions, etc.o Every s/w developer follows HOOKS seven principles for building the complex s/w system.

PRINCIPLE 1: THE REASON IT ALL EXISTS:-

The s/w system exists only to provide value to its users. So all decisions of system should made by considering requirements of user Before performing any activity ask yourself following questions : Does this add real values to the system? if no , do not do it. All other principles support this one.

PRINCIPLE 2: KEEP IT SIMPLE, STUPID:-

All s/w designs should be as simple possible, but no simpler. The s/w system should be easy to understood & easy to maintain.

PRINCIPLE 3: MAINTAIN THE VISION:-

A clear vision is essential & important to success of s/w project. If architectural vision of s/w system is weak, it will break well defined s/w system. The architect should hold the vision.

PRINCIPLE 4: WHAT YOU PRODUCE, OTHER WILL CONSUME:-

What you are doing that must be understood by someone else i.e. specification, design & implementation. Make design that should easy to implement. Make specification with an eye to users. Develop code which should able to extend & easy to maintain.

PRIMCIPLE 5: BE OPEN TO THE FUTURE:-

A system should have long lifetime period. S/w lifetimes are measured in months instead of years. True industrial strength s/w system must work far longer, to do this approach; s/w system must able to adopt the

changes. S/w system must solve general problem, not just specific one problem. This leads to reuse of entire system.

PRINCIPLE 6: PLAN AHEAD FOR REUSE:-

The advantage of reuse is to save efforts & time. High level of reuse is hardest goal to achieve in developing s/w system. There are many types of techniques to realize the reuse at every level of s/w system development process. Those techniques at detailed code & design level are documented. Question is: - how can you reuse something that you do not know exist?

PRINCLE 7: THINK:-

Placing clear, complete thought before action always produces better results. When someone think about something, he/she are likely to do it right also gain knowledge about how to do it right

again. And if he/she thinks about something & still does it wrong it becomes valuable experience.

COMMUNICATION PRACTICES:-o Requirement analysis always begins with communication between two or more parties.o When customer has computer related problem, a developer responses to customer request for help.o Following principles are applied to all forms of communication that occur within s/w project.

PRINCIPLE 1: LISTEN CAREFULLY:-

Listen carefully to understand customer requirements carefully & perfectly. This principle ensures the proper data collection from speaker. You should ask questions to get them clarifies. Try to avoid interruption in between the communication.

PRINCIPLE 2: PREPARATION BEFORE COMMUNICATION:-

It is very important to prepare agenda for meeting, which contains the points to be discussed.

PRINCIPLE 3: BE PREPARED, FACILITATE THE ACTIVITY:-

When the leader keeps the conversation moving in productive direction, that meeting will be called as successful communication meeting.

PRINCPILE 4: FACE TO FACE COMMUNICATION:-

Face to face communications is better, even some documents related to particular discussion, is given to all stakeholders.

PRINCIPLE 5: TAKE NOTES & DOCUMENT THE DECISION:-

Note down all important points raised in discussion.

PRINCIPLE 6: STRIVE FOR COLLABORASTION:-

For best team work, collaboration in team member is important. It is achieved when collective knowledge of members of team is united to illustrate the product.

PRINCIPLE 7: BE FOCUSED, MODULARIZE DISCUSSION:-

There are more people involved in communication, & the discussion will goes from one topic to next topic. The facilitator must keep conversation modular; leaving the one topic after it has been resolved.

PRINCIPLE 8: DRAW A PICTURE IF SOMETHING IS UNCLEAR:-

It applied only for verbal communication. A drawing provides clarity when a word fails to do job.

PRINCIPLE 9: a. Agree to something, move on. b. Cannot agree to something move on. c. If function is unclear and can’t be clarified at moment, move on.

There are many topics which requires discussion & that “moving on “is sometimes best way to achieve communication faster.

PRINCIPLE 10:- NEGOTIATION IS NOT A CONTEST:-

In many situations, the s/w developer & customer must negotiate about functions, priorities, features & delivery dates. If team has well collaborated, all parties have common goal, for this reason negotiation will demand compromise for all

parties.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

PLANNING PRACTICES:-o Planning activity consist of set technical & management practices which helps to achieve goal.o Following principles are used:-

PRINCIPLE 1: TO UNDERSTAND THE SCOPE OF THE PROJECT:- It provides the team with destination.

PRINCIPLE 2:- TO INVOLVE THE CUSTOMER IN PLANNING ACTIVITY:- The customer defines the project priorities and constraints, so s/w engineer must negotiate timelines, order delivery and

other project related issues.

PRINCIPLE 3:- TO RECOGNIZE THAT PLANNING IS ITERATIVE:-

The plan must be able to change. Iterative, incremental models dictate the replanning based on feedback received from customers.

PRINCIPLE 4:- TO ESTIMATE BASED WHAT YOU KNOW:-

The goal of estimation is to provide indication of cost, efforts, task duration based on the current understanding of work to be done.

If information is unreliable, estimates will be unreliable.

PRINCIPLE 5:- TO CONSIDER RISK AS YOU DEFINE THE PLAN:-

If software team has defined the risks which have high impact and probability then proper planning is necessary. So plan should adjust to accommodate the risks.

PRINCIPLE 6:- BE REALISTIC

Because of some reasons every member do not work 100% of the day. If there is problem in human communication, the changes will occur in requirement specification. Many times s/w engineers make the mistakes. So these realistic should be considered while developing the plan.

PRINCIPLE 7:- TO ADJUST GRANULARITY AS YOU DEFINE THE PLAN:-

Granularity means the level of detail that is introduced as project plan is developed.1. FINE GRANULARITY PLAN:-

- This plan provides the significant work task detail that is planned over short period of time.2. COARSE GRANULARITY PLAN:-

- It provides broader work task details that are planned over a long period of time. Granularity moves from fine to course as project time moves away from current date.

PRNCIPLE 8:- TO DEFINE HOW YOU INTEND TO ENSURE QUALITY.

The plan should identify how the team keeps ensuring quality. 2 techniques used, formal technical review and pair programming. The formal technical reviews can be scheduled. Pair programming is used during construction.

PRINCIPLE 9:- TO DESCRIBE HOW YOU INTEND TO ACCOMMODATE CHANGE.

The s/w team must know how the changes are made when s/w engineering work proceeds.

PRINCIPLE 10:- TO TRACK THE PLAN FREQUENTLY AND TO MAKE ADJUSTMENTS AS REQUIRED.

Many projects fall behind schedule one day at a time.

So track of progress is done on daily basis.

Looking for problem areas and whether scheduled work match with actual work or not.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

MODELING PRACTICES:-

o The models helps to gain understandings of actual entity to be built when entity is physical thing i.e. for building, you

can build small model.

o When entity is s/w design, SRS is developed.

o The models must capable of representing information, the architecture, functions, features and behavior of system.

o Two analysis modeling techniques are:-

1. “STRUCTURED ANALYSIS”:-

It is Classical modeling method.

This model depicts the information content and flow.

Have following goals:

i. The product of analysis must be maintainable.

ii. Problems of size must be deal with using effective method of partitioning.

iii. Graphics can be used if possible.

iv. We have to differentiate between logical and physical considerations.

2. “OBJECT ORIENTED ANALYSIS”:-

The objective of this model is to develop the series of models that describes s/w as it works to satisfy customer

requirements.

The intent is to define all classes that are related to the problem to be solved.

o Two types of models are created in s/w engineering :-

i. Analysis model :-

- Represent customer requirements by using following domains:

(a) Information domain

(b) Functional domain

(c) Behavior domain

ii. Design model:-

- Describes how the system will be implemented and structure of system.

- Represents the characteristics of s/w that helps to develop the software efficiently

(a) Architecture

(b) User interface

(c) Component level details

ANALYSIS MODELING PRINCIPLES:-o Investigators identify the analysis problem and cause of the problem.o Also develops modeling notations.o Principles of analysis model are:

PRINCIPLE 1:- INFORMATION DOMAIN OF PROBLEM MUST BE REPRESENTED AND UNDERSTOOD.

Information domain contains the data flow into system (I/P), the data that flow out of system (O/P) and data stores that collect and organize persistent data object.

PRINCIPLE 2:- FUNCITONS THAT THE SOFTWARE PERFORMS MUST BE DEFINED.

S/w functions provide benefit to end user, and also provide internal support for those features that are user visible. Some functions transfers data that flow into system or controls the internal s/w processing or external system elements.

PRINCIPLE 3:- BEHAVIOR OF SOFTWARE MUST BE REPRESENTED

The behavior of s/w is driven by interaction with external environment. Input data provided by users, control data provided by externally it all causes s/w to behave in specific way.

PRINCIPLE 4:- THE MODELS THAT DEPICT FUNCTION, INFORMATION AND BEHAVIOR MUST BE PARTITIONED IN SUCH A MANNER THAT UNCOVERS DETAILS IN A LAYERED FASHION.

Analysis modeling allows the practitioner to better understand problem & establish the solution. Complex problems are, solved using divide and conquer method. A large, complex and critical problem is divided into sub problems until each sub problem is easy to understand. This is

called partitioning.

PRINCIPLE 5:- ANALYSIS TASK SHOULD MOVE FROM ESSENTIAL INFORMATION TOWARD IMPLEMENTATION DETAIL.

Describes the problem from end user’s perspective. The essence of problem is explained, without considering, how solution will be developed.

DESIGN MODELIING PRINCIPLES:- o Design model is created for s/w, which provides variety of different views of s/w system.o There is no shortage of methods for deriving various elements of s/w design.a. Data- driven methods allows data structure to dictate architecture.b. Pattern driven methods uses information to develop process patterns.o Following are principles:-

PRINCIPLE 1: - The design should be traceable to the analysis modes:-

The analysis model describes the information domain of problem, functions and set of classes, system behavior. The design model translates the above information into:

a. Architecture.b. A set of subsystems that implements major function.c. A set of component level design.

PRINCIPLE 2:- THE DESIGN ALWAYS CONSIDERS THE ARCHITECTURE OF THE SYSTEM TO BE BUILT.

S/w architecture is the map or skeleton of s/w system to be built. S/w architecture affects the interfaces, program control flow, data structures, behavior, the manner in which testing can

be conducted, the maintainability of the system and so on.

For these reasons design should begin with architectural consideration.

PRINCIPLE 3:- THE DESIGN OF THE DATA IS IMPORTANT AS DESIGN OF PROCESSING FUNCTIONS.

Data design is essential and important element of s/w architectural design.

A well-structured data design helps to simplify program flow, makes the design and implementation of s/w easier.

Makes overall processing more efficient and effective.

PRINCIPLE 4:- THE INTERFACES MUST BE DESIGNED WITH CARE:-

Well-designed interfaces makes integration easier.

The interface should be simply designed.

The processing of interface should be efficient.

PRINCIPLE 5:- USER INTERFACE DESIGN SHOULD BE TUNNED TO THE NEED OF THE END-USER.

The user interface is the visible manifestation of the s/w.

A poor user interface design leads to perception that the s/w is bad.

PRINCIPLE 6:- THE COMPONENT-LEVEL DESIGN SHOULD BE FUNCTIONALLY INDEPENDANT.

The functionality which is delivered by the s/w component should be cohesive i.e. it should focus on one and the only

one function.

PRINCIPLE 7:- THE COMPONENTS SHOULD BE LOOSELY COUPLED TO EACH OTHER AND EXTERNAL

ENVIRONMENT.

Coupling is accomplished in 2 ways.

1. Via component interface.

2. Messaging through global data.

When level of coupling increases, the error propagation also increases and becomes difficult to maintain.

So component coupling should be low.

PRINCIPLE 8:- THE DESIGN MODELS SHOULD BE EASILY UNDERSTANDABLE.

The purpose of design is to communicate information to developers, who will create code, who will test the s/w, who

will maintain the s/w in future.

If design model is difficult and complex to understand, it will not serve as effective communication medium.

PRINCIPLE 9:- THE DESIGN SHOULD BE DEVELOPED ITERATIVELY:-

Design occurs iteratively like all other activities.

The first iteration of design is to refine the design and to correct an error.

But later iteration of design should strive to make the design as simple as possible.

CONSTRUCTION PRACTICES:-o Construction activity encompasses a set of coding and testing task that leads to development of s/w that is ready for

delivery to customer. o In modern s/w engineering work , coding may be following way:-

a. Direct creation of programing language source code such as JAVA.b. Automatic generation of source code using intermediate design like representation of component to be built.c. Automatic generation of executable code using “fourth generation programing language” such as c++.

o Levels of testing are :-1. Unit testing: - testing is done at component level.2. Integration testing: - conducted when all components are combined together.3. Validation testing:- checks whether requirements have been met or not.4. Acceptance testing: - conducted by customer to check all functions and features.

CODING PRINCIPLES:-o The coding principle guides the coding task which is based on programing languages, programing style and programing

methods.1. PREPARATION PRINCIPLES:- BEFORE YOU WRITE ONE LINE OF CODE, BE SURE YOU:

Understand the problem, you are trying to solve. Understand the basic design principles and concepts. Pick a programming language that meets the need of the s/w to be built and environment in which s/w will operate. Select program environment that provides tools that will make your work simple and easier. Create set of unit test that will be applied once your code is completed.

2. CODING PRINCIPLES:- As You Begin Writing Code, Be Sure you: Develop the algorithms by the following the structured programming practice. Use the pair programming. Select the data structure that will meet the need of design. Understand the s/w architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible. Create nested loops that must easy to test. Select meaningful variable names and follow logical coding steps. Write code that is self-documenting. Create visual layout that aids understanding.

3. VALIDATION PRINCIPLES:-AFTER YOU HAVE COMPLETED YOUR FIRST CODING PASS, BE SURE YOU: Conduct the code walkthrough when appropriate. Perform unit test and correct the errors you have discovered. Refactor the code.

TESTING PRINCIPLES:-o Testing objectives by Glen Myers are:-

a. Testing is process of executing a program to find out the errors.b. A good test case is one that has high probability of finding maximum numbers of errors.c. A successful test is one that uncovers all the errors.d. If test is successful, it will uncover all errors in s/w.e. Also checks whether s/w function is according to specification or not.f. Also checks a Behavioral and performance requirement has been meet or not.

o PRINCIPLES ARE:-

PRINCIPLE 1:- ALL TESTS SHOULD BE TRACEABLE TO CUSTOMER REQUIREMENTS:

The main objective of testing is to uncover errors that may cause the program to fail to meet its requirements.

PRINCIPLE 2:- TEST SHOULD BE PLANNED LONG BEFORE TESTING BEGINS:

When requirements are identified at that time test should be planned. Detailed definition of test case can begin when design model is completed. So all test can be planned and designed before code generation.

PRINCIPLE 3:- THE PARETO PRINCIPLE APPLIES TO S/W TESTING:

Pareto principle implies that 80% of all errors uncovered during testing of 20% code. Here the problem is to isolate these components and thoroughly test them.

PRINCIPLE 4:- TESTING SHOULD BEGING IN THE SMALL AND PROGRESS TOWARDS TESTING IN LARGE:

The first test planned and executed generally focus on individual components i.e. Unit test. As testing progresses, the focus is given to find out errors in integrated cluster of components and in entire system i.e.

integration testing.

PRINCIPLE 5:- EXHAUSTIVE TESTING IS NOT POSSIBLE:

For small or moderate sized program, the number of path permutation is large. So it is impossible to execute every combination of i/p during testing.

----------------------------------------------------------------------------------------------------------------------------------------------------------

SOFTWARE DEPLOYMENT:-o Deployment activity have 3 actions:-

1. Delivery cycle2. Support cycle3. Feedback cycle

1. Delivery cycle:- Provides the customer and end user with operational s/w increment that provides usable functions.

2. Support cycle:- Provides documentation and human assistance for all functions. This cycle is introduced during all deployment cycle.

3. Feedback cycle:- Provides the s/w team with guidance that result in modification to the function, features for next increment.

o Following are principles:-

PRINCIPLE 1:-MANAGE CUSTOMERS EXPECTIONS OR REQUIREMENTS:

Many times the customer wants changes in their initial requirements which has stated earlier and even through all requirements satisfied, then also customer is disappointed.

So at the time of s/w delivery, developer must have skills to manage customers’ expectations and requirements.

PRINCIPLE 2: - RECORD-KEEPING MECHANISM MUST BE ESTABLISHED FOR CUSTOMER SUPPORT.

Customer support is essential and important factor in deployment. The support should be well planned and with proper record keeping mechanism. Developers should keep the record of customer support.

PRINCIPLE 3:- PROVIDE ESSENTIAL INSTRUCTIONS, DOCUMENTATION and MANUAL:

Project delivery includes all documentations, help files and guidance for handling s/w by user.

PRINCIPLE 4:- ASEMBLE AND TEST COMPLETE DELIVERY PACKAGE:-

Customer must get all supporting and essential help from developer. So the CD with following support should be delivered:

i. Necessary supported operational feature and help.ii. Essential manuals required for s/w using. iii. All executable file of developed s/w. iv. Necessary installation procedures.

PRINCIPLE 5:- DO NOT DELIVER ANY DEFECTIVE OR BUGGY S/W TO THE CUSTOMER.

----------------------------------------------------------------------------------------------------------------------------------------------------------

REQUIREMENT ENGINEERING (RE):-o IEEE defines requirement as

1. “A condition that must be processed by system to satisfy contract specification or other document”.2. “A condition of capability needed by user to solve problem or achieve goal.”

o Requirement engineering is defined as,1. “The process of establishing the services the system should provide and environment under which it must

operate”.2. “The process of completing the customer requirements describes in terms of environment, goal, problems and

confirmation by all into well defined, structured document known as RDD (requirements definition and description)”.

o RE task lead to understand of what the business impact of s/w will be, what the customer wants and how user will interact with software.

o RE process normally involve writing requirements definition then expanding, this into requirement specification.o Following figure shows classes of reader concerned with different levels of specification.

1. Client engineers2. System architects3. Software Developers

1. Client engineers2. System architect3. System end user.4. Software Developers

1. Client managers2. Contract managers3. Client engineers4. System architect5. System end user.

Software Specification

Requirements Specification

Requirement Definition

1. REQUIREMENT DEFINATION :- Generated by customer. Statements are in natural language plus diagrams, of what services the system is expected to provide and the

environment under which it must operate.2. REQUIREMENTS SPECIFICATION OR FUNCTIONAL SPECIFICATION:- Structured documents consist of system services in detail. Serve as contract between customer and developer. 3. SOFTWARE SPECIFICATION Description of s/w. Used for designing, coding. Adds details to requirement specification.

o There is problem of separating the different levels of descriptions because the writers of all documents are different.o REQUIREMENT ENGINEERING HAS TWO PARTS:-

1. Requirement definition 2. Requirement management

User

Fig. RE Process

RE process starts with feasibility study of the requirements.

Then requirement elicitation is performed which focuses on gathering user requirements.

After that the analysis is performed which forms SRS.

Then requirements are checked for correctness and completeness in requirement validation.

Last to understand and control changes to the system, requirement management is performed.

Requirement Validation

Feasibility Study

Requirement Management

Requirement Specification

Requirement Elicitation

Requirement Analysis

SRS

Feasibility Report

o NEED OF RE:-1. The core process of RE is need analysis , problem definition , goal identification , requirement definition , solution

expectations , enables s/w engineers to determines the SRS to solve customer problem . 2. It is important to understand what the customer wants before you begin to design and built the s/w system.

o PRINCIPLES OF RE:-

PRINCIPEL 1:- UNDERSTAND THE PROBLEM BEFORE YOU BEGIN TO CREATE ANALYSIS MODEL:

If before understanding the problem, solution is developed, it may cause wrong solution.

PRINCIPLE 2:- DEVELOP PROTOTYPES THAT ENABLES A USER TO UNDERSTAND HOW HUMAN-MACHINE-INTERACTION WILL OCCUR:

The quality of s/w is based on “friendliness” of interface and prototyping.

PRINCIPLE 3:- RECORD THE ORIGIN OF AND THE REASON FOR EVERY REQUIREMENT:

All development should be traceable to customer.

PRINCIPLE 4:- USE MULTIPLE VIEWS OF REQUIREMENTS:

Data models, functional models and behavioral model are developed so it reduces missing of requirements.

PRICNEIPLE 5:- PRIORITIZE THE REQUIREMENTS:

If deadline is early, the highest priority s/w should be developed first. If incremental model is applied, highest priority requirements should be delivered in first increment.

PRINCIPLE 6:- WORK TO ELIMINATE AMBIGUITY:

Most requirements are described in natural language, there is possibility of ambiguity. To eliminate ambiguity, the formal technical reviews are performed.

o REQUIREMENTS ENGINEERING TASKS:- RE process is achieved through execution of seven functions:-

a. Inception b. Elicitation c. Elaboration d. Negotiation e. Specification f. Validation g. Management

Some of these functions occur in parallel.

These functions are performed to identify the needs or requirements of s/w projects means what the customer wants

and establish foundation for s/w design and construction.

1. INCEPTION :- (BEGINNING):-

Inception is said that ‘well beginning is half done’.

Developer is always confused about following questions:

a. How does s/w project get started?

b. Does the need evolve over time?

Project starts when the business need is identified or service is discovered.

Stakeholders try to identify depth and breadth of market and identify scope of the project.

Software engineers ask following questions:-1. Who is behind the request for this work?2. Who will use the solution?3. What will be economic benefit of successful solution?

2. ELICITATION:- “Means to draw out the truth from anybody”. It is a task that helps customer to define what is required. but it is difficult to identify the requirement because of:

a. PROBLEMS OF VALIDITY :- States are always changes

b. Problem of scope :- Many times customer states unnecessary project details so developer may get confused instead of

clarity of objective. c. PROBLEMS OF UNDERSTANGING :-

Sometimes customer and developer has poor understanding of:-1. Capabilities and limitations of computing environment.2. What is needed?3. Understanding of problem domain.

3. ELABORATION:- Means to work out in detail.

The collected information during inception and elicitation is expanded and modified.

Analysis models are developed.

User scenarios are also developed which describes how the user will interact with the software system.

The result of elaboration is analysis model which defines information, behavioral and functional domain of

problem.

4. NEGOTIATION:-

During this task, the financial and commercial issues are discussed.

Negotiation function is common for different customers to propose conflicting requirements, arguing that,

“their version is essential for our special needs”.

The requirements engineer solves conflict through process of negotiation.

Customers are asked to define requirements and discuss conflicts in priority.

Risks are analyzed and identified.

Using interactive approach, the requirements are combined, eliminate so each party achieves satisfaction.

5. SPECIFICATION:-

It is final work product produced by requirement engineer.

Specification serves as foundation for all activities.

Specification describes performance, function of system and also the environment.

Specification is in the form of:-

1. A set of graphical model

2. A written document

3. A prototype

4. Collection of scenarios

5. A formal mathematical model

6. VALIDATION:- All previous work completed will be useless or meaningless if it is not validation against customer

requirements. Validation includes:-

a. Does a requirement violate any system domain constraints?b. All requirements are stated early?c. Are the requirements misinterpreted?d. Is the system requirement traceable to the system model that is created?

Observes the specification to ensure that all the s/w requirements have been stated unambiguously. Also ensures that errors have been detected and corrected. Primary requirement of validation is formal technical review. There is one formal technical review team which includes s/w engineers, users and customers who examines

the specification, clarifies errors and find out missing information.

7. REQUIREMENT MANAGEMENT:- Starts with identification. Each and every requirement is assigned unique identifier. So traceable table is developed. These tables relate requirements to specific aspects of system. Following are different traceability tables :-

1. FEATURES TRACEABILITY TABLE:- - Shows how requirements relate to product features observed by customer

2. SOURCE TRACEABILITY TABLE:-- Identifies source of each requirement.

3. DEPENDENCY TRACEABILITY TABLE:- - Shows how requirements are related to one another.

4. SUBSYSTEM TRACEABILITY TABLE:-- Categorizes requirements by subsystem that they govern.

5. INTERFACE TRACEABILITY TABLE:-- Shows how requirements relate to internal or external interface.

AO1

AO2 AO3 AO4 AO5 ------ ------ AO11RO1RO2RO3RO4RO5------

ROn

Fig. Generic Traceability Table

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SRS(SOFTWARE REQUIREMENT SPECIFICATION):-

o SRS is, “a document that describes what the proposed software should do without describing how s/w will do it.”

o FEATURES OF SRS:-

1. It forms basis for s/w development.

2. Provides reference for validation of final s/w product.

3. It is the medium through the client needs are accurately specified and determined.

4. Helps to client to understand their needs and requirement.

5. Establish the basis for agreement between client and supplier.

o IEEE defines SRS as:-

“A document that clearly describes each of essential requirements of the s/w and external interfaces.”

o Each requirement is verified by performing the analysis, inspection, test etc.

o Depending on size and complexity of s/w product, SRS may consist of few pages.

o FOLLOWING SHOWS SIMPLIFIED OUTLINE WHICH MAY BE USED AS FRAMEWORK FOR

SPECIFICATION :

I.INTRODUCTION

II. INFORMATION DESCRIPTION

c. Information content representation d. Information flow representation

a. 1. Data flowb. 2. Control Flow

III. Functional Description

e. Functional partitioning f. Functional Description g. Control Description

h.

1. Processing Narrative2. Restrictions/Limitation3. Performance

Requirement4. Design Constraint5. Supporting Diagrams

IV. BEHAVIORAL DESCRIPTION

a. System Statesb. Events & Actions

a. Performance bounds b. Classes of tests c. Expected s/w responsed. Special consideration

V.VALIDITION CRITERIA

a. System referenceb. Overall Descriptionc. S/W Project Constraints

Overall description

Control Specification

Design Constraints

Fig:- s/w requirements specification outline

i. INTRODUCTION : -

States the goal and objective of s/w.

It is s/w scope.

ii. INFORMATION DESCRIPTION :-

Provides description of problem that the s/w must solve.

Information content and relationships, flow structures are documented.

H/W, S/W human interfaces are describes for external system elements and internal software functions.

iii. FUNCTIONAL DESCRIPTION :-

The description of each function is required to solve the problem is presented here.

A processing narrative is provided for each function.

Design constraints are stated and justified.

Performance, characteristics are stated.

Diagrams are also included to graphically represent structure of s/w and flow between functions and other

elements.

iv. BEHAVIORAL DESCRIPTION:

It examines the operation of software as a consequence of events and internal control.

Ask following questions

1. How do we recognize successful implementation?

2. What classes of test must be conducted to validate the function and performance?

v. VALIDATION CRITERIA:

Reviews of all other requirements.

Time & attention to be given to this section.

vi. BIBLIOGRAPHY:

Contains references to all documents relate to s/w.

It includes:-Other s/w engineering documentation, technical references, vendor literature and standards.

vii. APPENDIX:

Contains information that supplements the specification.

Tabular data, algorithms, charts, graphs are presented as appendices.

o ADVANTAGES OF SRS:

1. SRS establishes the basis for agreement between client and the supplier on what the s/w product will do.

2. SRS provides reference for validation of final product.

3. High quality SRS is prerequisite to high quality s/w.

VI. Bibliography

VII. Appendix

4. A high quality SRS reduces the development cost.

o SRS FORMAT:- It includes the user requirements for a system & detailed specification of system requirements. Following fig. shows SRS format:

Section 1:-product overview and summary

Section 2:- development, operating and maintenance environment

Section 3:- external interfaces and data flow

Section 4:- functional requirements

Section 5:- performance requirements

Section 6:- Exception Handling

Section 7:- early subsets and implementation priorities

Section 8:-foreseeable modifications and enhancement

Section 9:- acceptance criteria’s

Section 10:- design hints and guidelines

Section 11:- cross- reference index

Section 12:- glossary of terms

SECTION 1 and SECTION 2 represents an overview of product features and summarize the processing environments

for development, operation and maintenance of s/w product.

SECTION 3 specifies the externally observable characteristics of the software product and also includes user displays,

report formats, data flow diagrams and data dictionary.

SECTION 4 specifies the functional requirements for the software product. These functional requirements are expressed

in relational a oriented notation which specifies relationship among input, actions and output.

SECTION 5 specifies performance characteristics like response time, processing time, throughput, primary/secondary

memory constraints, and telecommunication bandwidth.

SECTION 6 specifies exception handling, including action to be taken and messages to be displayed in response to

undesired events, errors.Various categories of exception include temporary/permanent resource failure, incorrect/out of

range input data, variation of capacity limits etc.

SECTION 7 specifies priorities for system under development.

SECTION 8 specifies modifications and enhancement into product following initial product release.

SECTION 9 specify acceptance criteria, which specify functional and performance test that must be performed,

standards to be applied to source code, internal-external documentation like design specification, test plan ,user manual,

installation and maintenance procedures etc.

SECTION 10 specifies design hints and guidelined.Software design includes ‘How to’ implementation and should be

used while design phase of project.

SECTION 11 specifies source of information used in deriving the requirements.

SECTION 12 specifies definition of terms that may be unfamiliar to customer and developers.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Need/Importance of SRS:-

1. Three interested parties of software system are client, user, and developer. The clients communicate their

requirements with developer. But sometimes client does not understand software process and developer does not

understand client’s requirements. So it causes communication gap between parties.SRS helps to bridge this gap.

2. The purpose of SRS is to help the client to understand their needs.

3. SRS is important because it establishes basis for agreement between client and supplier.

4. SRS provides reference for validation of final product.

5. High quality SRS is prerequisite to high quality software.

6. It enables developers to consider the user requirements before designing the software. So it reduces rework,

development efforts.

7. SRS needed to provide feedback, which ensures to user that the organization understands the issues or problems to

be solved.

8. It determines requirements of software system so developer can make rough estimation of total cost and schedule of

the software project.

9. SRS uses validation strategies which can be applied to the requirements to acknowledge that requirements are stated

properly.

--------------------------------------------------------- END of 2nd Chapter. ------------------------------------------------------------------------