Explain Black box and White box testing? What are their advantages and disadvantages?

For complete testing of a software product both black and white box testing are necessary.

Black-box testing
This testing looks at the available inputs for an application and the expected outputs that should result from each input. It does not have any relation with the inner workings of the application, the process undertaken or any other internal aspect of the application. Search engine is a very good example of a black box system. We enter the text that we want to search, by pressing “search” we get the results. Here we are not aware of the actual process that has been implemented to get the results. We simply provide the input and get the results.

White-box testing
This testing looks into the complex inner working of the application; it tests the processes undertaken and other internal aspects of the application. While black box testing is mainly concerned with the inputs and outputs of the application, white box testing help us to see beyond i.e. inside the application. White-box testing requires a degree of sophistication which is not the case with the black-box testing, as the tester is required to interact with the objects that are used to develop an application rather than having easy access to the user interface. In-circuit testing is a good example of a white-box system testing where the tester is looking at the interconnections between different components of the application and verifying the proper functioning of each internal connection. We can also consider the example of an auto-mechanic who takes care of the inner workings of a vehicle to ensure that all the components are working correctly to ensure the proper functioning of the vehicle.

The basic difference between black-box and white-box testing is the areas of focus which they choose. We can simply say that black-box testing is focused on results. Where if an action is performed and the desired result is obtained then the process that has actually been used is irrelevant. White-box testing, on the other hand focuses on the internal working of an application and it is considered to be complete only when all the components are tested for proper functioning.

Advantages of Black-box testing
- Since tester does not have to focus on the inner working of an application, creating test cases is easier.
- Test case development is faster as tester need not to spend time on identifying the inner processes; his only focus is on the various paths that a user may take through GUI.
- It is simple to use as it focuses only on valid and invalid inputs and ensures that correct outputs are obtained.

Drawbacks of Black-box testing
Constantly changing GUI makes script maintenance difficult as the input may also be changing. Interacting with GUI may result in making the test script fragile and it may not properly execute consistently.

Advantages of White-box testing
- Since the focus is on the inner working the tester can identify objects pro grammatically. This can be useful when the GUI is frequently changing.
- It can improve stability and re usability of test cases provided the object of an application remains the same.
- By testing each path completely it is possible for a tester to achieve thoroughness.

Drawbacks of White-box testing
Developing test cases for white-box testing involves high degree of complexity therefore it requires highly skilled people to develop the test cases. Although to a great extent fragility is overcome in white-box testing BUT change in the objects name may lead to breaking of the test script.

What is Software Process? What do you mean by software quality factors? What are different process models?

The factors that affect the quality of the software are called quality factors. The software product quality has three dimensions and each of the dimension deals with a set of quality factors.

PRODUCT OPERATION
- Correctness
- Reliability
- Efficiency
- Integrity
- Usability
PRODUCT TRANSITION
- Portability
- Re usability
- Interoperability
PRODUCT REVISION
- Maintainability
- Flexibility
- Testability

Software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced.
Software process deals with the technical and management issues of software development.
The different process models are:
- Waterfall Model
The phases of the model are organized in a linear order.
- Prototyping
A throw away prototype is built instead of freezing the requirements before design or coding to help understand the requirements.
- Iterative
The software should be developed in increments with each functionality added to each increment.
- Spiral
Software development activities are organized like a spiral that has many cycles. The radial dimension represents the cumulative cost and the angular dimension represents the progress.

What is Software Project Management? List the number of tasks it consists.

In Software Project Management, the end users and developers need to know the length, duration and cost of the project. It is a process of managing, allocating and timing resources to develop computer software that meets requirements. It consists of eight tasks:
- Problem Identification
- Problem Definition
- Project Planning
- Project Organization
- Resource Allocation
- Project Scheduling
- Tracking, Reporting and Controlling
- Project Termination

In problem identification and definition, the decisions are made while approving, declining or prioritizing projects. In problem identification, project is identified, defined and justified. In problem definition, the purpose of the project is clarified. The main product is project proposal.

In project planning, it describes a series of actions or steps that are needed to for the development of work product. In project organization, the functions of the personnel are integrated. It is done in parallel with project planning.

In resource allocation, the resources are allocated to a project so that the goals and objectives are achieved. In project scheduling, resources are allocated so that project objectives are achieved within a reasonable time span.

In tracking, reporting and controlling, the process involves whether the project results are in accordance with project plans and performance specification. In controlling, proper action is taken to correct unacceptable deviations.

In project termination, the final report is submitted or a release order is signed.

What are steps involved in deriving test cases? What are Validation, Alpha, Beta testing? What are test metrics?

The steps in deriving the test cases using use cases are:
- Using the RTM, the use cases are prioritized. Importance is gauged based on the frequency with which each function of the system is used.
- Use case scenarios are developed for each use case. The detailed description for each use case scenario can be very helpful in later stage.
- For each scenario, take at least one test case and identify the conditions that
will make it execute.
- Data values are determined for each test case.

After system testing is culminated, validation testing is performed which consists of a series of black box tests. It focuses on user-visible actions and user-recognizable output.
Alpha and Beta Testing are a series of acceptance tests. Alpha testing is performed in a controlled environment normally at developer's site. In alpha testing, developers record all errors and usage problems while end users use the system. Beta testing is done at customer's site and developers are not present. In beta testing, end-users records all errors and usage problems.

The amount of testing effort needed to test object oriented software can be indicated by the metrics used for object-oriented design quality. These metrics are:
- Lack of Cohesion in Methods (LCOM)
- Percent Public and Protected (PAP)
- Public Access To Data Members (PAD)
- Number of Root Classes (NOR)
- Number of Children (NOC) and Depth of the Inheritance Tree (DIT)

What is Test Driven Development Methodology and its benefits?

Test-driven Development(TDD)is a method of developing software that adopts a test
first approach plus refactoring. The test-first approach is a programming technique, involving analysis, design, coding and testing all together. Refactoring is used to improve the design of the code without changing the observable behavior of the software, it changes the internal structure. It is cleaning up the bad code. In test-driven development, each new test provides feedback into the design process which helps in driving design decisions.

WHAT ARE DIFFERENT BENEFITS OF TEST DRIVEN DEVELOPMENT

- It allows simple incremental development.
- It involves a simpler development process.
- It provides constant regression testing.
- It improves communication.
- It improves understanding of required software behavior.
- It centralizes knowledge.
- It improves software design.

WHAT ARE DIFFERENT STEPS IN TEST DRIVEN DEVELOPMENT

- Write a test that defines how the software should behave.
- Make the test run as easily and quickly as possible.
- Clean up the code.

After integration testing, the system is tested as a whole for functionality and fitness of use. It includes performance testing, stress testing, security testing, recovery testing.
In object oriented, test requirements are derived from analysis artifacts or work products that use UML such as the class diagrams,sequence diagrams and collaboration diagrams. Use case diagram is a good source to derive test cases. They represent high functionality. Use cases are not independent. They have sequential dependencies. A scenario is an instance of a use case, or a complete path through the use case.

How are programs tested? Explaining Unit Testing and Integration Testing

In testing programs, individual units are tested and this comes under unit testing. Then, their relationship with one another is tested which comes under integration testing.

UNIT TESTING

- It tests the smaller building blocks of a program.
- It confirms that each module performs its assigned task.
- It involves testing the interface, local data structures, boundary conditions, independent paths and error handling paths.
- Two things are used for unit testing : Driver and Stub.
- Driver is a program that accepts test case data, passes data to the component to be tested, and prints relevant results.
- Stub is program that performs support activities such as data manipulation, queries of states of the component being tested and prints verification of entry.

INTEGRATION TESTING

- Integration testing is followed after unit testing.
- All classes are tested for integration.
- Each component performs correctly within collaboration and that each interface is correct.
- Integration testing can be done by thread based testing approach. A thread is a path of communication among classes that needs to process a single input or respond to an event.
- Regression testing is re-execution of some subset of tests to ensure that changes have not produced unintended side effects.

Software Test Case Design Methods - Black Box Testing Methods

Black box testing focuses on:
- testing thefunctional aspect of the software.
- input conditions are derived that will test all functional requirements.
- set of test cases that finds incorrect or missing functions.
- interface errors.
- data structure errors.
- external database excess errors.
- performance errors.
- initialization and termination errors.

Black box techniques include:

- Graph based testing is a black-box testing technique that uses objects that are modeled in software and the relationships among these objects. Steps involved in designing test cases using graph based testing are:

STEP 1: Create a graph of software objects and identify the relationship of these objects.
STEP 2: Traverse the graph to define test cases.

- Equivalence Testing
A black box testing technique which divides the input domain into partitions or into sets of data from which test cases can be derived. These test cases are used to uncover errors. It makes use of equivalence classes which are sets of valid and invalid states that an input may be in.

- Boundary Value Testing
It is a black box testing method that uses the boundaries of the input domain to derive test cases. If input condition specifies range bounded by n and m, the test cases that can be derived use values n and m, just above n and m, just below n and m.

If input condition specifies number of values, the test cases that can be derived are use the minimum, use the maximum, just above and below minimum, just above and below maximum.

How to implement Controllers - Programming Guidelines

To implement controllers, a good programming practice is to use abstract classes and interfaces. It increases the ability of the software to be reusable and manageable. It allows the software to have plug and play options.

WHAT IS AN ABSTRACT CLASS

Abstract class is a class that cannot be instantiated. It is located at the top of an object oriented class hierarchy. It defines the actions possible with objects of all subclasses of class. The methods defined in abstract class are called abstract methods.

WHAT IS AN INTERFACE

Interfaces define the signatures of a set of methods withoutthe body. Interfaces define a standard and public way of specifying the behavior of classes. Interface can only contain abstract methods, properties but we don’t need to put abstract and public keyword. All the methods and properties defined in Interface are by default public and abstract. Interfaces exhibits polymorphism.

- Interfaces are needed when similar methods are implemented by unrelated classes.
- Through interfaces, we can actually capture similarities among unrelated classes without artificially forcing a class relationship.
- Interfaces are needed to reveal an object's programming interface without revealing its class.
- Interfaces are needed to model multiple inheritance which allows aclass to have more than one superclass.

IMPLEMENTATION METRICS

The metrics used for implementation are the metrics for the design. These are:
- Lines of Code (LOC)
- Number of classes.
- Number of documentation pages.
- Total cost.
- Effort.

What are different programming guidelines ?

Programming is a skill and the programmer should be given the flexibility to implement the code. Guidelines that should be kept in mind during programming are:

- Pseudocodes can be used to adapt the design to the chosen programming language. They are structured English that describes the flow of a program code. The design is an outline of what is to be done in component and in which the programmer adds his creativity and expertise. Codes can be rearranged orreconstructed with a minimum of rewriting.

- Control structure is based on messages being sent among objects of classes, system states and changes in variables. It is important for the program structure to reflect the design's control structure. Modularity, Coupling, Cohesion are good design characteristics that must be translated to program characteristic.

- Documentation guidelines is a set of written description that explain to the reader what the programs do and how they do it. Two program documentation are created:

Internal documentation is a descriptive document directly written within the source code. A summary information is provided to describe its data structures, algorithms, and control flow.

External Documentation consists of other documents that are not part of the source code but is related to the source code. The preconditions and post conditions of the source code are identified in object oriented system.

What are different programming standards and procedures?

Translating design can be a difficult task. Two problems can be encountered:
- The designer of the system might not able to address the specifics of the platform and programming environment.
- The codes should be written in away that is understandable not only to the programmer who did it but also by other programmers and testers.
- The programmer must take advantage of the characteristics of the design's organization, the data's structure and programming language constructs while still creating code that is easily maintainable and reusable.

What are different programming standards and procedures

Sometimes when writing a code,several people are involved. Thus,a great deal of cooperation and coordination is required. Programming standards and procedures are important for several reasons.
- Thoughts can be organized and mistakes can be avoided.
- How to document the source codes to make them clear?
- Faults can be located.
- It helps in the translation from the design code to the source code.
- It can assists other team members such as software testers, software integrators and software maintainers.
- Smooth ens the coordination and communication.

Implementation Specific Standards

- Platform where the software will be developed and used.
- Standards on the source code documentation.
- Standards for correspondence between design and source codes.
- Design characteristics such as low coupling, high-cohesion and well-defined interfaces.

What is Deployment Level Design ? What are Design Metrics?

DEPLOYMENT LEVEL DESIGN

The Deployment-level Design creates a model that shows the physical architecture of the hardware and software of the system. The Deployment Diagram is made up of nodes and communication associations. Nodes would represent the computers. The communication associations show network connectivity. To develop deployment level design, distribute the software components identified in the component-level design to the computer node where it will reside.

DESIGN METRICS

There are many sets of metrics for the object-oriented software. Chidamber and Kemere Metrics suite consist of six class based design metrics:
Weighted Methods per Class (WMC)
- This is computed as the summation of the complexity of all methods of a class.

Depth of the Inheritance Tree (DIT)
- It is defined as the maximum length from the root superclass to the lowest subclass.

Number of Children (NOC)
- Children of a class are the immediate subordinate of that class.
- As the number of children increases, reuse increases.
- Of course, as the number of children increases, the number of testing the children of the parent class also increases.

Coupling Between Object Classes (CBO)
- It is the number of collaboration that a class does with other object.
- As this number increases, the re-usability factor of the class decreases.

Response for a class (RFC)
- It is the number of methods that are executed in response to a message given to an object of the class.
- As this number increases, the effort required to test also increases because it increases the possible test sequence.

Lack of Cohesion in Methods (LCOM)
- It is the number of methods that access an attribute within the class.
- If this number is high, methods are coupledtogether through this attribute.

What are data design, interface design, report design, form design?

DATA DESIGN

- Data design is a software engineering task.
- It creates a model of the data in a more implementation specific representation.
- Data design is a process of gradual refinement, from the coarse to the precise data structures and processes that provide it.
- Data design includes identifying the data, defining specific data types and storage mechanisms, and ensuring data integrity.

INTERFACE DESIGN

- Interface design comprises of designing elements that facilitate how software communicates with humans, devices and other systems that interoperate with it.
- Consistency should be maintained.
- Designing good forms, reports and screens are critical in determining how the system will be acceptable to end-users.

REPORT DESIGN

Reports can be placed on an ordinary paper, continuous forms, screen-based or microfilm or microfiche. Things that should be kept in mind while designing reports are:
- Number of Copies and Volume
- Report Generation
- Report Frequency
- Report Figures
- Media

FORM DESIGN
Forms are usually used for input when a workstation is not available. The following are the steps in designing forms.
- Instructions should appear on the form except when the same person fills itover and over again.
- Use familiar words.
- The answer space should be enough for user to comfortably enter all necessary information.
- Lower case print is easier to read that uppercase.

Model-View-Controller (MVC) Design Pattern

Model View Controller design pattern is used to support multiple types of users with multiple types of interfaces. The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes:

- Model: The model locates all data information for the application. It does not care about how you interpret it or how process it. It divides functionality among objects involved in maintaining and presenting data to minimize the degree of coupling between the objects.

- View: The view manages the display of information. It is responsible for maintaining the consistency in its presentation when the underlying model changes.

- Controller: The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate. The actions performed on the model can be activating device, business process or changing the state of a model.

The MVC pattern allows any number of controllers to modify the same model. The strategies by which MVC can be implemented are as follows:
- For Web-based clients such as browsers, use Java Server Pages (JSP) to render the view, Servlet as the controller, and Enterprise JavaBeans (EJB) components as the model.
- For Centralized controller, a main servlet is used to make control more manageable.

What are different types of design patterns?

The Composite View Design Pattern
- The context of composite view pattern is that it allows the development of the view more manageable through the creation of a template to handle common page elements for a view.
- The problem comes in modifying and managing the layout of multiple views.
- The solution is to use this pattern when a view is composed of multiple atomic sub-views. Each component of the template may be included into the whole and the layout of the page may be managed independently of the content.
- A benefit of using this pattern is that interface designer can prototype the layout of the page, plugging in static content on each component.
- The drawback is that there is a runtime overhead associated with it.

The Front Controller Design Pattern
- It provides a centralized controller for managing requests.
- The problem is that the system needs a centralized access point for presentation-tier request handling to support the integration of system data retrieval, view management, and navigation.
- The solution to the above problem is that a controller is used as an initial point of contact for handling a request. It centralizes decision-making controls.

Data Access Object Design Pattern
- It separates resource's client interface from its data access mechanisms.It allows data access mechanism to change independently of the code that uses the data.
- The problem is that data will be coming from different persistent storage mechanism and access mechanism varies based on the type of storage.
- The solution to the above problem is to use the Data Access Object to abstract and encapsulate all access to the data source. It implements the access mechanism required to work with the data source.

What are different characteristics of design patterns?

A design pattern is a general repeatable solution to a commonly occurring problem in software design.
- It is a proven solution to problems that keep recurring.
- They are reusable solutions to common problems.
- Design patterns are not frameworks.
- Design patterns are more abstract than frameworks.
- Design pattern cannot be directly implemented.
- Design patterns are more primitive than a framework.
- A design pattern cannot incorporate a framework.
- Patterns may be documented using one of several alternative templates.
- Design patterns can speed up the development process by providing tested, proven development paradigms.
- Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
- Patterns allow developers to communicate using well-known, well understood names for software interactions.

A pattern description includes the following elements:
- name of the pattern should be meaningful.
- context of the pattern represents the circumstances or preconditions.
- Problem description that pattern addresses should be provided.
- Solution is a description of the static and dynamic relationships amongthe components of the pattern.
The use of design patterns requires careful analysis of the problem that is to be
addressed and the context in which it occurs.

What is Software Architecture ? What are subsystems and interfaces?

Software architecture defines a set of decisions about the organization. It includes:
- how to select structural elements.
- how to select their interfaces.
- how to select the behavior.
- how to select the composition of these structural and behavioral elements into larger subsystems.
- architectural style that guides this organization.
A software architecture is a description of the sub-systems and components of a software system and the relationships between them.
Software architecture is layered structure of software components and the manner in which these components interact.
A software architecture is modeled using package diagram of UML. A package is a model element that can contain other elements.
A subsystem is a combination of package and class. The advantages of defining subsystem are:
- Development of smaller units is possible.
- Re-usability increases.
- Handling complexity is managed properly.
- Maintainability eases.
- Supports portability.

An interface is a set of operations.
- Allows the separation of the declaration of behavior from the realization of the behavior.
- Serves as a contract to help in the independent development of the components by the development team, and ensures that the components can work together.
- There are two styles of communication subsystems use: client-server and peer-to-peer communication.

What is Design Engineering? What are different design concepts?

Design engineering focuses on the creation of a representation or model that are concentrated on architecture of the software, data structures, interfaces and components that are necessary to implement the software.

The design process is an iterative process of refinement, i.e.from a higher level of abstraction to lower levels of abstraction. The design should implement both explicit and implicit requirements. It should be readable and understandable. It provides an over-all illustration of the software from the perspective of the data, function and behavior.

Design concepts provides the software engineer a foundation from which design methods can be applied. These concepts include:
- Abstractions: Software engineers different levels of abstractions as we design the blueprint of the software. Two types of abstraction called data and procedural abstractions are defined.
- Modularity: It leads to information hiding and encourages functional independence.
- Coupling: It is the degree of interconnectedness between design objects. Two types of coupling are used: Interaction and Inheritance Coupling.
- Cohesion: It is the measure to which an element contributes to a single purpose.
- Refinement: Abstraction complements refinement as they enable a software engineer to specify the behavior and data of a class or module yet suppressing low levels of detail.
- Refactoring: It simplifies the design of the component without changing its function and behavior.

The work product of the design engineering phase is the design model which consists of the architectural design, data design, interface design and component-level design and deployment level design.

Software Test Case Design Methods - White Box Testing Methods

Software is tested in two ways:
- First approach is test the internal workings of software. It is also called white box testing.
- Second approach is to test the software as a whole, i.e., know how the software works and tests if it conforms to the specified functionality in the requirements. It is also called black box testing.

White Box Testing Techniques

It is a test case design technique that uses the internal control structure of the software component. It is also called glass box testing. It ensures that no logical errors, incorrect assumptions and typographical errors have been missed. The test cases that are included are testing all logical conditions, loops, independent paths, internal data structures. Techniques involved are:

- Basis Path Testing
It enables the test case designer to derive a logical complexity measure based on the procedural specification of a software component.
STEP 1: Use a procedural specification as input in deriving the basic set of execution path.
STEP 2: Draw the flow graph of the procedural specification.
STEP 3: Compute for the complexity of the code.
STEP 4: Determine the basic set of execution paths.
STEP 5: Document the test cases based on the identified execution path.

- Control Structure Testing
A white box testing technique that tests three types of program control - condition testing, loop testing and data flow testing.
Condition testing test the logical conditions contained in a procedural specification.
Looping testing is a method that focuses exclusively on the validity of iterative constructs or repetition.
Data Flow Testing method selects test paths of a program according to the locations of the definitions and uses of variables in the program.

What is Software Testing? What are its goals and principles?

Software testing is a process to detect the defects and faults before it is given to the end-users. The goal of software testing is to identify them.
- Fault Identification is the process of identifying the cause of failure; they may be several.
- Fault Correction and Removal is the process of making changes to the software and system to remove the fault.

The main objectives of software testing are:
- To design a test case with high probability of finding undiscovered bugs.
- To execute the program with the intent of finding bugs.

The principles of software testing are:
- As part of traceability analysis, every test should be able to be raced back to the requirements.
- Test should be planned long before testing begins.
- Testing should begin “in small” and progress toward testing “in the large”.
- An independent third party should conduct the test.

Software Testing Strategies integrate software test case design methods into a well planned series of steps that result in the successful implementation of the software.
A test specification is developed by the leader of quality assurance group. A Test Specification is an overall strategy that defines the specific tests that should be conducted.
Software testing begins from a single component using white-box and black-box techniques to derive test cases. Once the class is tested, integration of the class through communicationand collaboration with other tested classes is tested. The main goal is to uncover as many errors as possible.

What is Requirement Metrics? What is Requirement Profile Test?

Requirements measurement focuses on three areas: process, product and resources.
- Requirement size can be a good input for estimating software development effort.
- As software development progresses, the requirement size can be tracked down.
- As design and development occur, we would have a deeper understanding of the problem and solution.
- A large number of changes indicates some instability and uncertainty in our understanding of what the system should do or how it should behave.

Requirements can be used to determine if the requirements are ready to be turned over to them by designers and testers. Requirement Profile test is a technique employed to determine the readiness to turn over requirements to the designers or testers.
For Designers
- System Designer Rate 1: It means the designer understands the requirements completely.
- System Designer Rate 2: It means that there are aspects of the requirement that are new to designer, however, they are not radically different from requirements that he has defined.
- System Designer Rate 3: It means that there are aspects of the requirement that are very different from requirement that the designer has designed before, however he understands it and is confident that he can develop a good design.
- System Designer Rate 4: It means that there are parts of this requirement that he does not understand, not confident that he can develop a good design.
- System Designer Rate 5: It means that he does not understand the requirement at all and a design cannot be developed.

For Testers:
- System Tester Rate 1: It means that he understands the requirements completely and that he has tested similar requirements previously.
- System Tester Rate 2: It means that there are aspects of the requirement that are new to tester however, they are not radically different from requirements that he has tested before.
- System Tester Rate 3: It means that there are aspects of the requirement that are very different from requirement that the tester has tested before, however he understands it and is confident that he can test it.
- System Tester Rate 4: It means that there are parts of this requirement that he does not understand, not confident that he can devise a test to address this requirement.
- System Tester Rate 5: It means that he does not understand the requirement at all and he cannot develop a test to address it.

Requirements Traceability Matrix (RTM) - A tool for managing requirements

The Requirements Traceability Matrix is a tool for managing requirements. It is not only used in requirements engineering but through out the software engineering process. The white box approach refers to the development of system requirements without
considering the technical implementation of those requirements.

Components of Requirements Traceability Matrix

- RTM ID: A unique identification number for a specific requirement.
- Requirements: This is a structured sentence describing the requirements in a "shall" format.
- Notes: These are additional notes of requirements.
- Requestor: This is the person who requested the requirement.
- Date: This is the date and time the requirement was requested by requestor.
- Priority: This is the priority given to the requirements.

While the above elements are the initial RTM, one can customize the matrix to tie the requirements with other work products or documents. It can be done by:

- Relative to RTM ID: It specifies if the current RTM is directly or indirectly related to other requirements.
- Statement of Work (SOW): This is a description that relates the requirements directly back into a specific paragraph within the Statement of Work. It is a document that specify the nature of the engagement of the development team with their clients.

The components and the use of the RTM should be adapted to the needs of the process, project and product. It grows as the project moves along.

Requirement Model - Obtained during Elaboration phase

During elaboration, the information that is obtained from inception and elicitation are refined and expanded to produce two models:
- Requirements Model
- Analysis Model

The requirement model provides a model of the system or problem domain. It consists of three things:

Use Case Model
Use case model describes what the system does. It serves as a contract between the customers, end users and developers. The Use CaseModel consists of two parts, namely, the use case diagrams and use case specifications.
The use case diagram shows the functionality that the system provides and which users will communicate with the system. It consists of actors and use cases.
The use case specifications are textual documents that specify properties of the use cases.

Supplementary Specifications
Requirements that do not map to a specific use case are part of supplementary specifications. These requirements may be non functional or system constraints. Non functional requirements includes maintainability of the source codes, usability, reliability, performance, and supportability. System constraints restricts our choices for constructing a solution.

Glossary
It defines a common terminology for all models. This is used by the developers to establish a common dialect with customers and end-users.

What are different tasks of requirement engineering - Elaboration,Negotiation,Specification,Validation,Management

Elaboration involves the information that is obtained from team during inception and elicitation is expanded and refined. It focuses on defining, redefining and refining of models. It tries to model the "WHAT" rather than the "HOW".
- Requirement is created using methods that capitalize on user scenarios.It describes how the end-users and actors interact with the system.
- The analysis model is derived from the requirements model where each scenario is analyzed to get the analysis classes.
- The requirements model and the analysis model are the main workproduct of this task.

Negotiation involves customers, stakeholders and software development team reconcile conflicts. The purpose of negotiation is to develop a project plan that meets the requirements of the user while reflecting real-world constraints such as time,people and budget. Negotiation includes:
- always remember negotiation is not completion.
- always have a strategy.
- always listen effectively.
- always focus on other party's interest.
- never make it personal.
- always be creative.
- be ready to commit.

Specification is the final artifact or work product produced by the software engineer during requirements engineering. It serves as the foundation for design and construction of software.

In Validation,the work products produced as a consequence of requirements engineering are assessed for quality. It checks whether inconsistencies, omissions, and errors have been detected and corrected. The
review team that validates the requirements look for errors in content or interpretation,areas where clarification is required, missing information, inconsistencies,conflicting and unrealistic requirements.

Management is a set of activities that help the project team identify, control, and track requirements and their changes at any time as the project progresses.

What are concepts of Requirements Engineering? Different tasks of requirement engineering - Inception and Elicitation.

Requirement Engineering encompasses a set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-user will interact with the software. The basic agreement between end-users and developers on what the software should do is given by requirement engineering.

It gives stakeholders anopportunity to define their requirements understandable to the development team. Designing and building an elegant computer program that solves the wrong problem is a waste. This is the reason why it is important to understand what customer wants before one begins to design and build a computer-based system. Requirements Engineering builds a bridge to design and construction.

There are seven distinct tasks to requirements engineering namely inception, elicitation, elaboration, negotiation, specification, validation and management.

INCEPTION

At inception, the problem scope and its nature is defined.
To initiate requirement engineering, steps include:
- identify stakeholders.
- recognize multiple viewpoints.
- work towards collaboration.
- ask the first question.
The main output or work product of inception task is a one or two pages of
product request which is a paragraph summary of the problem and its nature.

Elicitation

Elicitation is a task that helps the customer define what is required. The problems encountered are problems of scope, problems of understanding, problems of volatility. Elicitation makes use of a requirements elicitation format that combines the elements of problem solving, elaboration, negotiation, and specification.
Joint Application Development is one collaborative requirement gathering technique that is popularly used to elicit requirements.
The tasks involved in elicitation can be categorized into three groups, namely, pre-joint meeting tasks, joint meeting tasks and post-joint meeting tasks.

Quality Function Deployment is a technique that emphasizes an understanding of what is valuable to the customer. It identifies three types of requirements normal requirements, expected requirements and exciting requirements.

The output of the elicitation task can vary depending on size of thesystem or product to be built. For most systems, the output or work products include a statement of need and feasibility, a bounded statement of scope for the system or product, a list of customer, users, and other stakeholders who participated in requirements elicitation, a description of the system's technical environment and a priority list of requirements, preferably, in terms of functions, objects and domain constraints that apply to each.

What role does documentation plays in development process?

Documentation is a set of documents or informational products to describe a computer system. Each document is designed to represent particular function like reference, instructional and motivational.
Some types of documentation and informational products are system features and functions, user and management summaries, users manual, video and multimedia, tutorials, demonstrations, reference guide, technical references, system test models,
operations/operators manual, wall charts, newsletters.

A useful document furthers the understanding of the system's desired andactual behavior and structure. The criteria for measuring usability of documents are readability, availability, suitability and accessibility.

Purpose of Documentation

- It provides a reasonably permanent statement of a system's structure or behavior through reference manuals, user guides and systems architecture documents.
- It serves as transitory documents that are part of the infrastructure involved in running real projects.

Importance of Documents and Manuals

- Cost saving.
- They serve as sales and marketing tools.
- They serve as tangible deliverables.
- They serve as contractual obligations.
- They serve as security blankets.
- They serve as testing and implementation aids.
- They are used to compare the old and new systems.

Users involved in Development Process and End-Users who are involved indirectly in the development process...

GUIDELINES FOR END-USERS
The higher the level of the manager, the less he or she is likely to care about computer technology.
The goals and priorities of management may be in conflict with those of the supervisory and operational users.
Management may not provide resources, funding or time that the users feel is necessary to build an effective system.

The end users involved indirectly in the development process are auditors, standard bearers, and quality assurance group.
The objective of this group is to ensure that the system is developed in accordance with various standard set:
- standards by other departments.
- standards by government regulatory agencies.
- accounting standards.
- they do not get involved until the end of project.
- they provide the necessary notation and format of documentation.

Development Team
It is responsible in building the software that will supporta domain specific system.
System Analyst
Responsibility is understanding the system. Within this system, he identifies customer wants, and documents and prioritizes requirements.
System Designer
Responsibility is to transform a technology free architectural design that will providethe framework within which the programmers can work.
Programmers
Responsibility of the programmers is to write the codes of the software using a particular programming language based on system design.
Testers
Work product should be reviewed for faults and errors. It ensures thatwork products meet requirements and standards defined.