Vous êtes sur la page 1sur 40

UNIT 1

SOFTWARE PROCESS AND PROJECT MANAGEMENT


1. What is software engineering?
Software engineering is a discipline in which theories, methods and tools are applied to
develop professional software.
2. What is Software?
Software is nothing but a collection of computer programs that are related documents that
are indented to provide desired features, functionalities and better performance.
3. What are the characteristics of the software?
Software is engineered, not manufactured.
Software does not wear out.
Most software is custom built rather than being assembled from components.
4. What are the various categories of software?
System software
Application software
Engineering/Scientific software
Embedded software
Web Applications
Artificial Intelligence software
5. What are the challenges in software?
Copying with legacy systems.
Heterogeneity challenge
Delivery times challenge
6. Define software process.
Software process is defined as the structured set of activities that are required to develop
the software system.
7. What are the fundamental activities of a software process?
Specification
Design and implementation
Validation
Evolution
8. What are the umbrella activities of a software process?
Software project tracking and control.
Risk management.
Software Quality Assurance.
Formal Technical Reviews.

Software Configuration Management.


Work product preparation and production.
Reusability management.
Measurement.

9. What are the merits of incremental model?


The incremental model can be adopted when tere are less number of people
involved in the project.
Technical risks can be managed with each increment.
For a very small time span,at least core product can be delivered to the customer.
10. List the task regions in the Spiral model.
Customer communication In this region it is suggested to establish customer
communication.
Planning All planning activities are carried out in order to define resources
timeline and other project related activities.
Risk analysis The tasks required to calculate technical and management risks.
Engineering In this the task region, tasks required to build one or more
representations of applications are carried out.
Construct and release All the necessary tasks required to construct, test, install
the applications are conducted. _Customer evaluation Customer s feedback is
obtained and based on the customer evaluation required tasks are performed and
implemented at installation stage.
11. What are the drawbacks of spiral model?
It is based on customer communication. If the communication is not proper then
the software product that gets developed will not be the up to the mark.
It demands considerable risk assessment. If the risk assessment is done properly
then only the successful product can be obtained.
12. What is System Engineering?
System Engineering means designing, implementing, deploying and operating systems
which include hardware, software and people
13. List the process maturity levels in SEIs CMM.
o Level 1:Initial Few processes are defined and individual efforts are taken.
o Level 2:Repeatable To track cost schedule and functionality basic project
management processes are established.
o Level 3:Defined The process is standardized, documented and followed.
o Level 4:Managed Both the software process and product are quantitatively
understood and controlled using detailed measures.
o Level 5:Optimizing Establish mechanisms to plan and implement change.
14. What is an effector process?
The effector process is a process that verifies itself.The effector process exists in certain
criteria.

15. Define the computer based system.


The computer based system can be defined as a set or an arrangement of elements that
are organized to accomplish some predefined goal by processing information.
16. What does Verification represent?
Verification represents the set of activities that are carried out to confirm that the
software correctly implements the specific functionality.
17. What does Validation represent?
Validation represents the set of activities that ensure that the software that has been built
is satisfying the customer requirements.
18. What are the steps followed in testing?
Unit testing The individual components are tested in this type of testing.
Module testing Related collection of independent components are tested.
Sub-system testing This is a kind of integration testing. Various modules are
integrated into a subsystem and the whole subsystem is tested.
System testing The whole system is tested in this system.
Acceptance testing This type of testing involves testing of the system with
customer data. If the system behaves as per customer need then it is accepted.
19. What is the use of CMM?
Capability Maturity Model is used in assessing how well an organisations processes
allow to complete and manage new software projects.
20. Name the Evolutionary process Models.
Incremental model
Spiral model
WIN-WIN spiral model.
Concurrent Development
21. What is requirement engineering?
Requirement engineering is the process of establishing the services that the customer
requires from the system and the constraints under which it operates and is developed.
22. What are the various types of traceability in software engineering?
Source traceability These are basically the links from requirement to stakeholders
who propose these requirements.
Requirements traceability These are links between dependant requirements.
Design traceability These are links from requirements to design.

Part B
1. Explain Iterative, Waterfall and Spiral model for software life cycle and various
activities in each phase.
Iterative model
In Iterative model, iterative process starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just part of the
software, which is then reviewed in order to identify further requirements. This process is
then repeated, producing a new version of the software at the end of each iteration of the
model.
Iterative Model design
Iterative process starts with a simple implementation of a subset of the software requirements
and iteratively enhances the evolving versions until the full system is implemented. At each
iteration, design modifications are made and new functional capabilities are added. The basic
idea behind this method is to develop a system through repeated cycles (iterative) and in
smaller portions at a time (incremental).
Following is the pictorial representation of Iterative and Incremental model:

Iterative and Incremental development is a combination of both iterative design or iterative


method and incremental build model for development. "During software development, more
than one iteration of the software development cycle may be in progress at the same time."
and "This process may be described as an "evolutionary acquisition" or "incremental build"
approach."

In incremental model the whole requirement is divided into various builds. During each
iteration, the development module goes through the requirements, design, implementation
and testing phases. Each subsequent release of the module adds function to the previous
release. The process continues till the complete system is ready as per the requirement.
The key to successful use of an iterative software development lifecycle is rigorous
validation of requirements, and verification & testing of each version of the software against
those requirements within each cycle of the model. As the software evolves through
successive cycles, tests have to be repeated and extended to verify each version of the
software.
Iterative Model Application
Like other SDLC models, Iterative and incremental development has some specific
applications in the software industry. This model is most often used in the following
scenarios:

Requirements of the complete system are clearly defined and understood.


Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
There is a time to the market constraint.
A new technology is being used and is being learnt by the development team while
working on the project.
Resources with needed skill set are not available and are planned to be used on
contract basis for specific iterations.
There are some high risk features and goals which may change in the future.

Iterative Model Pros and Cons


The advantage of this model is that there is a working model of the system at a very early stage
of development which makes it easier to find functional or design flaws. Finding issues at an
early stage of development enables to take corrective measures in a limited budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky software
development projects. This is because it is hard to break a small software system into further
small serviceable increments/modules.
The following table lists out the pros and cons of Iterative and Incremental SDLC Model:
Advantages
Some working functionality can be developed quickly and early in the life cycle.
Results are obtained early and periodically.
Parallel development can be planned.
Progress can be measured.
Less costly to change the scope/requirements.
Testing and debugging during smaller iteration is easy.
Risks are identified and resolved during iteration; and each iteration is an easily managed
milestone.
Easier to manage risk - High risk part is done first.
With every increment operational product is delivered.

Issues, challenges & risks identified from each increment can be utilized/applied to the
next increment.
Risk analysis is better.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical projects.
During life cycle software is produced early which facilitates customer evaluation and
feedback.
Disadvantages
More resources may be required.
Although cost of change is lesser but it is not very suitable for changing requirements.
More management attention is required.
System architecture or design issues may arise because not all requirements are gathered
in the beginning of the entire life cycle.
Defining increments may require definition of the complete system.
Not suitable for smaller projects.
Management complexity is more.
End of project may not be known which a risk is.
Highly skilled resources are required for risk analysis.
Projects progress is highly dependent upon the risk analysis phase.
Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a linearsequential life cycle model. It is very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and there is no overlapping in the
phases.
Waterfall model is the earliest SDLC approach that was used for software development .
The waterfall Model illustrates the software development process in a linear sequential flow;
hence it is also referred to as a linear-sequential life cycle model. This means that any phase in
the development process begins only if the previous phase is complete. In waterfall model phases
do not overlap.
Waterfall Model design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development
is divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as
the input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.

SDLC Waterfall Model


The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible requirements of the system to be


developed are captured in this phase and documented in a requirement specification doc.

System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.

Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.

Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.

Deployment of system: Once the functional and non functional testing is done, the
product is deployed in the customer environment or released into the market.

Maintenance: There are some issues which come up in the client environment. To fix
those issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model phases do not overlap.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are:

Requirements are very well documented, clear and fixed.

Product definition is stable.

Technology is understood and is not dynamic.

There are no ambiguous requirements.

Ample resources with required expertise are available to support the product.

The project is short.

Waterfall Model Pros & Cons


Advantage
The advantage of waterfall development is that it allows for departmentalization and control. A
schedule can be set with deadlines for each stage of development and a product can proceed
through the development process model phases one by one.
Development moves from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds
in strict order.
Disadvantage
The disadvantage of waterfall development is that it does not allow for much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in the concept stage.
The following table lists out the pros and cons of Waterfall model:

Pros
Simple and easy to understand and use

Cons
No working software is produced until

Easy to manage due to the rigidity of the


model . each phase has specific
deliverables and a review process.
Phases are processed and completed one
at a time.
Works well for smaller projects where
requirements are very well understood.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well
documented.

late during the life cycle.


High amounts of risk and uncertainty.
Not a good model for complex and
object-oriented projects.
Poor model for long and ongoing
projects.
Not suitable for the projects where
requirements are at a moderate to high
risk of changing. So risk and uncertainty
is high with this process model.
It is difficult to measure progress within
stages.
Cannot accommodate changing
requirements.
Adjusting scope during the life cycle
can end a project.
Integration is done as a "big-bang. at the
very end, which doesn't allow
identifying any technological or
business bottleneck or challenges early.

SDLC - Spiral Model


The spiral model combines the idea of iterative development with the systematic, controlled
aspects of the waterfall model.
Spiral model is a combination of iterative development process model and sequential linear
development model i.e. waterfall model with very high emphasis on risk analysis.
It allows for incremental releases of the product, or incremental refinement through each
iteration around the spiral.
Spiral Model design
The spiral model has four phases. A software project repeatedly passes through these phases in
iterations called Spirals.

Identification: This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous communication


between the customer and the system analyst. At the end of the spiral the product is
deployed in the identified market.

Design: Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and final design
in the subsequent spirals.

Construct or Build: Construct phase refers to production of the actual software product
at every spiral. In the baseline spiral when the product is just thought of and the design is
being developed a POC (Proof of Concept) is developed in this phase to get customer
feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These
builds are sent to customer for feedback.

Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer evaluates
the software and provides feedback.

Following is a diagrammatic representation of spiral model listing the activities in each phase:
SDLC Spiral Model

Based on the customer evaluation, software development process enters into the next iteration
and subsequently follows the linear approach to implement the feedback suggested by the
customer. The process of iterations along the spiral continues throughout the life of the software.

Spiral Model Application


Spiral Model is very widely used in the software industry as it is in synch with the natural
development process of any product i.e. learning with maturity and also involves minimum risk
for the customer as well as the development firms. Following are the typical uses of Spiral
model:

When costs there is a budget constraint and risk evaluation is important.

For medium to high-risk projects.

Long-term project commitment because of potential changes to economic priorities as the


requirements change with time.

Customer is not sure of their requirements which is usually the case.

Requirements are complex and need evaluation to get clarity.

New product line which should be released in phases to get enough customer feedback.

Significant changes are expected in the product during the development cycle.

Spiral Model Pros and Cons


The advantage of spiral lifecycle model is that it allows for elements of the product to be added
in when they become available or known. This assures that there is no conflict with previous
requirements and design.
This method is consistent with approaches that have multiple software builds and releases and
allows for making an orderly transition to a maintenance activity. Another positive aspect is that
the spiral model forces early user involvement in the system development effort.
On the other side, it takes very strict management to complete such products and there is a risk of
running the spiral in indefinite loop. So the discipline of change and the extent of taking change
requests is very important to develop and deploy the product successfully.
The following table lists out the pros and cons of Spiral SDLC Model:

Pros
Changing requirements can be
accommodated.
Allows for extensive use of prototypes
Requirements can be captured more
accurately.

Cons
Management is more complex.
End of project may not be known early.
Not suitable for small or low risk projects
and could be expensive for small projects.
Process is complex

Users see the system early.


Spiral may go indefinitely.
Development can be divided into
Large number of intermediate stages requires
smaller parts and more risky parts can
excessive documentation.
be developed earlier which helps better
risk management.

2. Explain about the incremental model. (16)


Incremental Model
The incremental model may be viewed as a modification to the waterfall model. As
software projects increased in size, it was recognized that it is much easier, and
sometimes necessary, to develop the software if the large projects are subdivided into smaller
components, which may thus be developed incrementally and iteratively. In the early days,
each component followed a waterfall process model, passing through each step
iteratively. In the incremental model the components were developed in an overlapping
fashion, as shown in Figure. The components all had to be integrated and then tested
as a whole in a final system test. The incremental model provided a certain amount of
risk containment. If any one component ran into trouble, the other components were able to
still continue to be developed independently. Unless the problem was a universal one,
such as the underlying technology being faulty, one problem would not hold up the
entire development process.
Another perspective in utilizing the incremental model is to first develop the core
software that contains most of the required functionality. The first increment may be
delivered to users and customers as Release 1. Additional functionality and supplemental
features are then developed and delivered separately as they are completed, becoming
Release 2, Release 3, and so on. Utilizing the incremental model in this fashion
provides an approach that is more akin to an evolutionary software product development. When utilized in this development mode, the model in Figure would not have the
integration bucket.
The incremental model in Figure would have individual releases. For example,
Requirement 1 would be the core functionality release. Other requirements would each
depict different deliveries. Figure depicts the incremental, multiple release scenario where
the first release, Release 1, is the core function, followed by subsequent releases that may
include fixes of bugs from previous releases along with new functional features. The multiple
release incremental model also makes it possible to evolve the first release, which may
have flaws, into an ideal solution through subsequent releases. Thus it facilitates
evolutionary software development and management, a model that has been advocated by
many, especially by Tom Gilb who has written recently about the evo process (2004).
The number of releases for a software project will depend on the nature and goals of
the project. Although each release is independently built, there is a link between

releases because the existing design and code of the previous release is the basis upon
which future releases are built.

Both incremental models utilize the divide and conquer methodology where a large,
complex problem is decomposed into parts. The difficulty with this model is that such
problems are also intertwined, making the decoupling of the parts into independently
implementable components difficult. It will require a deep understanding of the problem, the
solution, and the usage environment. Overlapping the different increments is
another area of difficulty in that there may be some amount of sequential dependency of
information among the components. How much overlapping can take place depends on
how much prerequisite information is required.
Advantages and Disadvantages of Incremental Development
Advantages

Suitable for a large project but have limited financial resources. It is because, the
maintenance will be undertaken to improve the errors are not known at the beginning
of the cycle.
Repetition of the phases can be built so that the system really meet the needs of users
Establish a good relationship between users and developers. project team will always
communicate with users to obtain information to meet the needs of users,
Reduce the risk of delay due to the important work done first.
Produce software that can be easily used by consumers

Disadvantage

High maintenance costs

Difficult, it is because developers have to plan in advance the desired results. In


addition, the developer must ensure that the work was completed in time to avoid
delays and increased costs

3. Explain COCOMO Model in detail?


Software products are said to be feasible if they are developed within the budget constraints. The
cost estimation models are used to predict the effort and cost required to develop a project .These
models give a base to predict the cost for developing a software project. The cost estimation can
be used to develop a product utilizing optimum resources. In this paper we will be discussing
Constructive Cost Model as the cost estimation model.
Software cost estimation model is an indirect measure, which is used by software
personnel to predict the cost of a project. The development of software product varies depending
upon the environment in which it is being developed. For projects with familiar environment it is
easy to predict the cost of the project. The estimation model is useful for trade-off between the
developer and customer. Organization can realize of what is achievable and deliverable to the
customer.
For the organization to develop a cost estimation model the following things are
required.

List important or critical cost drivers.


Prepare a scaling model for each cost driver.
Find projects with similar environments.
Compare the project with previous familiar projects.
Evaluate the project whether it is feasible within the budget constraints.
Incorporate the critical features in an iterative manner.

Cost drivers are those critical features which have an impact on the project. The cost
drivers may vary the cost of building a project. The most important cost driver is size of the
project. Size of the project is measured in Kilo lines of code (KLOC). Function points are the
empirical measurement to measure size of the project. Function points may vary the size of the
project due to the variation in

Number of inputs
Number of outputs
Number of inquires
Number of files
Number of interfaces

CONSTRUCTIVE COST MODEL (COCOMO):

Constructive Cost model was developed by Barry W Boehm in 1981. It is an algorithmic


cost model. Algorithmic cost model is developed based on relating the current project to
previous projects. It is based on historical information. Cocomo is based on size of the project.
The size of the project may vary depending upon the function points.
COCOMO MODELS:

BASIC COCOMO
It is used for relatively small project.
Only a few cost drivers are associated.
Cost drivers depend upon project size mainly.
Useful when the team size is small, i.e. small staff.

The effort (E) and schedule (S) of the project are calculated as follows
Effort E = a * (KDSI) b * EAF Where KDSI is number of thousands of delivered source
instructions a and b are constants, may vary depending on size of the project.
Schedule S= c * (E) d
where E is the Effort and c, d are constants.
EAF is called Effort Adjustment Factor which is 1 for basic cocomo , this value may vary
from 1 to 15.[3]
Constants
Project modes

Organic project mode

2.4

1.05

2.5

0.38

Semi-detached project mode

3.0

1.12

2.5

0.35

Embedded project mode

3.6

1.20

2.5

0.32

Table 1
The above table 1 shows typical constant values that have been calculated from various projects.
The basic cocomo gives the magnitude of cost of the project. It varies depending upon
size of the project. The various classes of software projects are

Organic mode projects :


Used for relatively smaller teams.
Project is developed in familiar environment.
There is a proper interaction among the team members and they coordinate
their work.
Bohem observed E=2.4(KDSI)1.05 E in person-months.
And S=2.5(E)0.38.

Semi-detached mode projects :


It lies between organic mode and embedded mode in terms of team size.
It consists of experienced and inexperienced staff.
Team members are unfamiliar with the system under development.
Bohem observed E=3(KDSI)1.12 E in person-months.
And S=2.5(E)0.35.
Embedded mode projects :
The project environment is complex.
Team members are highly skilled.
Team members are familiar with the system under development.
Bohem observed E=3.6(KDSI)1.20 E in person-months.
And S=2.5(E)0.32.

Intermediate COCOMO
It is used for medium sized projects.
The cost drivers are intermediate to basic and advanced cocomo.
Cost drivers depend upon product reliability, database size, execution and
storage.
Team size is medium.
Advanced COCOMO
It is used for large sized projects.
The cost drivers depend upon requirements, analysis, design, testing and
maintenance.
Team size is large.

LIMITATIONS OF COCOMO

COCOMO is used to estimate the cost and schedule of the project, starting from the
design phase and till the end of integration phase. For the remaining phases a separate
estimation model should be used.
COCOMO is not a perfect realistic model. Assumptions made at the beginning may vary
as time progresses in developing the project.
When need arises to revise the cost of the project. A new estimate may show over budget
or under budget for the project. This may lead to a partial development of the system,
excluding certain requirements.
COCOMO assumes that the requirements are constant throughout the development of
the project; any changes in the requirements are not accommodated for calculation of cost
of the project.

There is not much difference between basic and intermediate COCOMO, except during
the maintenance and development of the software project.
COCOMO is not suitable for non-sequential, rapid development, reengineering, reuse
cases models.

COST ESTIMATION ACCURACY


The cost estimation may vary due to changes in the requirements, staff size, and environment in
which the software is being developed.
The calculation for cost estimation accuracy is given as follows
Absolute error= (Epred - Eactual)
Percentage error= (Epred - Eactual)/Eactual
Relative error= 1/n (Epred - Eactual)/Eactual
The above results give a more accurate estimation of costs for future projects. The cost
estimation model now becomes more realistic.
4. Explain in detail about project scheduling & EVA?
Earned Value Analysis (EVA) is an industry standard method of measuring a project's progress
at any given point in time, forecasting its completion date and final cost, and analyzing variances
in the schedule and budget as the project proceeds. It compares the planned amount of work with
what has actually been completed, to determine if the cost, schedule, and work accomplished are
progressing in accordance with the plan. As work is completed, it is considered "earned". The
Office of Management & Budget prescribed that EVA is required on construction projects.
"Agencies must use a performance-based acquisition management system, based on ANSI/EIA
Standard 748, to measure achievement of the cost, schedule and performance goals."
EVA is a snapshot in time, which can be used as a management tool as an early warning system
to detect deficient or endangered progress. It ensures a clear definition of work prior to beginning
that work. It provides an objective measure of accomplishments, and an early and accurate
picture of the contract status. It can be as simple as tracking an elemental cost estimate
breakdown as a design progresses from concept through to 100% construction documents, or it
can be calculated and tracked using a series of mathematical formulae (see below). In either case,
it provides a basis for course correction. It answers two key questions:
At the end of the project, is it likely that the cost will be less than, equal to or greater than the
original estimate?

Will the project likely be completed on time?


Work Breakdown Structure (WBS)
EVA works most effectively when it is compartmentalized, i.e. when the project is broken down
into an organized Work Breakdown Structure, or WBS. The WBS is used as the basic building
block for the planning of the project. It is a product-oriented division of project tasks that ensures
the entire Scope of Work is captured and allows for the integration of technical, schedule, and
cost information. It breaks down all the work scope into appropriate elements for planning,
budgeting, scheduling, cost accounting, work authorization, progress measuring, and
management control. The two most common WBS systems are the Construction Specifications
Institute (CSI) format, and the Uniformat. Often at the preliminary stages of design the
Uniformat lends a better understanding of the cost centers, and at final bid level of documents
often the CSI format is used. The indirect costs of design, oversight, and management must be
included in the WBS to reflect the full budget.
Calculating Earned Value
Earned Value Management measures progress against a baseline. It involves calculating three
key values for each activity in the WBS:
The Planned Value (PV), (formerly known as the budgeted cost of work scheduled or
BCWS)that portion of the approved cost estimate planned to be spent on the given activity
during a given period.
The Actual Cost (AC), (formerly known as the actual cost of work performed or ACWP)the
total of the costs incurred in accomplishing work on the activity in a given period. This Actual
Cost must correspond to whatever was budgeted for the Planned Value and the Earned Value
(e.g. all labor, material, equipment, and indirect costs).
The Earned Value (EV), (formerly known as the budget cost of work performed or BCWP)
the value of the work actually completed.
These three values are combined to determine at that point in time whether or not work is being
accomplished as planned. The most commonly used measures are the cost variance:
Cost Variance (CV) = EV - AC
and the schedule variance:
Schedule Variance (SV) = EV - PV

These two values can be converted to efficiency indicators to reflect the cost and schedule
performance of the project. The most commonly used cost-efficiency indicator is the cost
performance index (CPI). It is calculated thus:
CPI = EV / AC
The sum of all individual EV budgets divided by the sum of all individual AC's is known as the
cumulative CPI, and is generally used to forecast the cost to complete a project.
The schedule performance index (SPI), calculated thus:
SPI = EV / PV
is often used with the CPI to forecast overall project completion estimates.
A negative schedule variance (SV) calculated at a given point in time means the project is behind
schedule, while a negative cost variance (CV) means the project is over budget.
Earned Value Management System (EVMS)
A list of guidelines is provided which covers areas such as planning, scheduling & budgeting;
accounting issues; management reports, and so forth, however there are no "approved" systems
identified. But the basics of any EVMS are:
A methodical, organized, thorough, and complete WBS
A baseline schedule
A baseline budget, organized into control accounts
Measurement of the work by control account (e.g. units in place, man-hours, etc.)
Scheduling the authorized work is no different than in any large construction projectit is a
necessary activity for the success of the project. However in an EVMS the schedule will
integrate all of the technical, cost, and schedule aspects of the work, resulting in the expected
sequence of work. Interdependencies are established that result in the total work time and reveal
the critical path, which is also the shortest project duration.
Within each task it is then necessary to identify objective interim measures to allow for accurate
performance assessment each month. A sufficient number of these interim measures will be
defined after the detailed schedule is established to ensure the performance is measured as
accurately as possible.

A time-phased budget baseline, at the control account level, must also be established and
maintained. The assignment of budgets to work activities or tasks results in a plan against which
actual performance can be measured. This is referred to as the performance measurement
baseline (PMB), and it should be established as early as possible after notice to proceed has been
issued. The PMB includes direct hours/dollars, direct material dollars, equipment and any other
direct costs, and any indirect costs for the agreed scope. The indirect costs associated with
design, oversight, and management must also be included. Essentially the PMB represents the
formal plan for the project manager to accomplish all the work required in the time allotted and
within the budget provided.
ANSI 748 also requires "On at least a monthly basis, generate schedule variance data that
provide visibility into root causes and establish actions to achieve project completion. The first
intent if this criterion is to establish the fact that analysis, to remain viable, must be accomplished
on a regular, periodic basis. The second intent is to foster analyses and identification of root
cause and resulting impacts at the control account level."
The monthly performance report must include:
Budget, earned value, and actual costs (reconcilable with accounting system)
Cost Variance (CV)
Schedule Variance (SV)
Variance at Completion (VAR)
A variance analysis narrative (root causes, impacts at completion, and management actions)

UNIT II
REQUIREMENTS ANALYSIS AND SPECIFICATION
1. What is requirement engineering?
Requirement engineering is the process of establishing the services that the customer requires
from the system and the constraints under which it operates and is developed.
2. What are the various types of traceability in software engineering?
i. Source traceability These are basically the links from requirement to stakeholders
ii. Requirements traceability These are links between dependant requirements.
iii. Design traceability These are links from requirements to design.
3. Define software prototyping.
Software prototyping is defined as a rapid software development for validating the requirements.
4. What are the benefits of prototyping?
1. Prototype serves as a basis for deriving system specification. ii. Design quality
can be improved.
2. System can be maintained easily.
3. Development efforts may get reduced.
4. System usability can be improved.
5. What are the prototyping approaches in software process?
i. Evolutionary prototyping In this approach of system development, the initial prototype is
prepared
and it is then refined through number of stages to final stage.
ii. Throw-away prototyping Using this approach a rough practical implementation of the
system is produced. The requirement problems can be identified from this implementation. It is
then discarded. System is then developed using some different engineering paradigm.
6. What are the advantages of evolutionary prototyping?
i. Fast delivery of the working system.
ii. User is involved while developing the system.
iii. More useful system can be delivered.
iv. Specification,design and implementation work in co-ordinated manner.
7. What are the various Rapid prototyping techniques?
i. Dynamic high level language development. ii. Database programming.
iii. Component and application assembly.

8. What is the use of User Interface prototyping?


This prototyping is used to pre-specify the look and feel of user interface in an effective way.
9. What are the characteristics of SRS?
i. Correct The SRS should be made up to date when appropriate requirements are identified.
ii. Unambiguous When the requirements are correctly understood then only it is possible to
write an unambiguous software.
iii. Complete To make SRS complete,it shold be specified what a software designer wants to
create software.
iv. Consistent It should be consistent with reference to the functionalities identified.
v. Specific The requirements should be mentioned specifically.
vi. Traceable What is the need for mentioned requirement?This should be correctly identified.
10. What are the objectives of Analysis modeling?
i. To describe what the customer requires.
ii. To establish a basis for the creation of software design.
iii. To devise a set of valid requirements after which the software can be built.
11. What is data modeling?
Data modeling is the basic step in the analysis modeling. In data modeling the data objects are
examined independently of processing. The data model represents how data are related with one
another.
12. What is a data object?
Data object is a collection of attributes that act as an aspect, characteristic, quality, or descriptor
of the object.
13. What are attributes?
Attributes are the one, which defines the properties of data object.
14. What is cardinality in data modeling?
Cardinality in data modeling, cardinality specifies how the number of occurrences of one object
is related to the number of occurrences of another object.
15. What does modality in data modeling indicates?
Modality indicates whether or not a particular data object must participate in the relationship.

16. What is ERD?


Entity Relationship Diagram is the graphical representation of the object relationship pair. It is
mainly used in database applications.
17. What is DFD?
Data Flow Diagram depicts the information flow and the transforms that are applied on the data
as it moves from input to output.
18. What does Level 0 DFD represent?
Level0 DFD is called as fundamental system model or context model. In the context model
the entire software system is represented by a single bubble with input and output indicated by
incoming and outgoing arrows.
19. What is a state transition diagram?
State transition diagram is basically a collection of states and events. The events cause the
system to change its state. It also represents what actions are to be taken on the occurrence of
particular event.
20. Define Data Dictionary.
The data dictionary can be defined as an organized collection of all the data elements of the
system with precise and rigorous definitions so that user and system analyst will have a common
understanding of inputs, outputs, components of stores and intermediate calculations.
21. What are the elements of Analysis model?
i. Data Dictionary
ii. Entity Relationship Diagram
iii. Data Flow Diagram
iv. State Transition Diagram v. Control Specification
vi. Process specification

Part-B
1. Explain in detail about Functional and non-functional requirements. (16)
Requirements
The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements can
be obvious or hidden, known or unknown, expected or unexpected from clients point of view.

Functional requirement
In Software engineering and systems engineering, a functional requirement defines a function of
a system or its component. A function is described as a set of inputs, the behavior, and outputs.
Functional requirements may be calculations, technical details, data manipulation and processing
and other specific functionality that define what a system is supposed to accomplish. Behavioral
requirements describing all the cases where the system uses the functional requirements are
captured in use cases. Functional requirements are supported by non-functional requirements
(also known as quality requirements), which impose constraints on the design or implementation
(such as performance requirements, security, or reliability). Generally, functional requirements
are expressed in the form "system must do <requirement>", while non-functional requirements
are "system shall be <requirement>". The plan for implementing functional requirements is
detailed in the system design. The plan for implementing non-functional requirements is detailed
in the system architecture.
As defined in requirements engineering, functional requirements specify particular results of a
system. This should be contrasted with non-functional requirements which specify overall
characteristics such as cost and reliability. Functional requirements drive the application
architecture of a system, while non-functional requirements drive the technical architecture of a
system.
In some cases a requirements analyst generates use cases after gathering and validating a set of
functional requirements. The hierarchy of functional requirements is: user/stakeholder request
feature use case business rule. Each use case illustrates behavioral scenarios through one
or more functional requirements. Often, though, an analyst will begin by eliciting a set of use
cases, from which the analyst can derive the functional requirements that must be implemented
to allow a user to perform each use case.
Some of the more typical functional requirements include:
Business Rules
Transaction corrections, adjustments and cancellations
Administrative functions
Authentication
Authorization levels
Audit Tracking
External Interfaces
Certification Requirements
Reporting Requirements
Historical Data
Legal or Regulatory Requirements
Process

A typical functional requirement will contain a unique name and number, a brief summary, and a
rationale. This information is used to help the reader understand why the requirement is needed,
and to track the requirement through the development of the system.
The crux of the requirement is the description of the required behavior, which must be clear and
readable. The described behavior may come from organizational or business rules, or it may be
discovered through elicitation sessions with users, stakeholders, and other experts within the
organization. Many requirements may be uncovered during the use case development. When this
happens, the requirements analyst may create a placeholder requirement with a name and
summary, and research the details later, to be filled in when they are better known.
Non Functional requirements
In systems engineering and requirements engineering, a non-functional requirement is a
requirement that specifies criteria that can be used to judge the operation of a system, rather than
specific behaviors. They are contrasted with functional requirements that define specific
behavior or functions. The plan for implementing functional requirements is detailed in the
system design. The plan for implementing non-functional requirements is detailed in the system
architecture, because they are usually Architecturally Significant Requirements.
Broadly, functional requirements define what a system is supposed to do and non-functional
requirements define how a system is supposed to be. Functional requirements are usually in the
form of "system shall do <requirement>", an individual action of part of the system, perhaps
explicitly in the sense of a mathematical function, a black box description input, output, process
and control functional model or IPO Model. In contrast, non-functional requirements are in the
form of "system shall be <requirement>", an overall property of the system as a whole or of a
particular aspect and not a specific function. The system's overall properties commonly mark the
difference between whether the development project has succeeded or failed.
Non-functional requirements are often called "quality attributes" of a system. Other terms for
non-functional requirements are "qualities", "quality goals", "quality of service requirements",
"constraints" and "non-behavioral requirements". Informally these are sometimes called the
"ilities", from attributes like stability and portability. Qualitiesthat is non-functional
requirementscan be divided into two main categories:

Execution qualities, such as security and usability, which are observable at run time.
Evolution qualities, such as testability, maintainability, extensibility and scalability, which are
embodied in the static structure of the software system

Non-functional requirements cover all the remaining requirements which are not covered by the
functional requirements. They specify criteria that judge the operation of a system, rather than
specific behaviours, for example: Modified data in a database should be updated for all users
accessing it within 2 seconds.
Some typical non-functional requirements are:

Performance for example Response Time, Throughput, Utilization, Static Volumetric


Scalability
Capacity
Availability
Reliability
Recoverability
Maintainability
Serviceability
Security
Regulatory
Manageability
Environmental
Data Integrity
Usability
Interoperability

2. Explain in detail about user requirements. (16)


The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements can
be obvious or hidden, known or unknown, expected or unexpected from clients point of view.
Requirement Engineering
The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and descriptive
System Requirements Specification document.
Requirement Engineering Process
It is a four step process, which includes

Feasibility Study
Requirement Gathering
Software Requirement Specification
Software Requirement Validation

Let us see the process briefly Feasibility study


When the client approaches the organization for getting the desired product developed, it comes
up with rough idea about what all functions the software must perform and which all features are
expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired
system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyzes whether
the software product can be practically materialized in terms of implementation, contribution of
project to organization, cost constraints and as per values and objectives of the organization. It
explores technical aspects of the project and product such as usability, maintainability,
productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should be
undertaken.
Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the client and
end-users to know their ideas on what the software should provide and which features they want
the software to include.
Software Requirement Specification
SRS is a document created by system analyst after the requirements are collected from various
stakeholders.
SRS defines how the intended software will interact with hardware, external interfaces, speed of
operation, response time of system, portability of software across various platforms,
maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of
system analyst to document the requirements in technical language so that they can be
comprehended and useful by the software development team.
SRS should come up with following features:

User Requirements are expressed in natural language.


Technical requirements are expressed in structured language, which is used inside the
organization.
Design description should be written in Pseudo code.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.
Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are
validated. User might ask for illegal, impractical solution or experts may interpret the
requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
Requirements can be checked against following conditions If they can be practically implemented
If they are valid and as per functionality and domain of software
If there are any ambiguities
If they are complete
If they can be demonstrated
Requirement Elicitation Process
Requirement elicitation process can be depicted using the following diagram:

Requirements gathering - The developers discuss with the client and end users and know their
expectations from the software.
Organizing Requirements - The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.
Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and conflicts, they
are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.
Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake in the
software system development.
There are various ways to discover requirements
Interviews
Interviews are strong medium to collect requirements. Organization may conduct several types
of interviews such as:

Structured (closed) interviews, where every single information to gather is decided in


advance, they follow pattern and matter of discussion firmly.
Non-structured (open) interviews, where information to gather is not decided in advance,
more flexible and less biased.
Oral interviews
Written interviews
One-to-one interviews which are held between two persons across the table.
Group interviews which are held between groups of participants. They help to uncover any
missing requirement as numerous people are involved.

Surveys
Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.
Questionnaires
A document with pre-defined set of objective questions and respective options is handed over to
all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied and
requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people in the domain can be a great
help to analyze general and specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no
software installed at clients end for developers reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback serves as an input
for requirement gathering.

Observation
Team of experts visit the clients organization or workplace. They observe the actual working of
the existing installed systems. They observe the workflow at clients end and how execution
problems are dealt. The team itself draws some conclusions which aid to form requirements
expected from the software.
Software Requirements Characteristics
Gathering software requirements is the foundation of the entire software development project.
Hence they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:
Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Credible source
Software Requirements
We should try to understand what sort of requirements may arise in the requirement elicitation
phase and what kinds of requirements are expected from the software system.
Broadly software requirements should be categorized in two categories:
Functional Requirements
Requirements, which are related to functional aspect of software fall into this category.
They define functions and functionality within and from the software system.
Examples Search option given to user to search from various invoices.
User should be able to mail any report to management.
Users can be divided into groups and groups can be given separate rights.
Should comply business rules and administrative functions.
Software is developed keeping downward compatibility intact.

Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this category. They
are implicit or expected characteristics of software, which users make assumption of.
Non-functional requirements include Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Disaster recovery
Accessibility
3. Explain in detail elicitation and analysis. (16)
Requirements Analysis
Software engineering task bridging the gap between system requirements engineering and
software design.
Provides software designer with a model of:
system information
function
behavior
Model can be translated to data, architectural, and component-level designs.
Expect to do a little bit of design during analysis and a little bit of analysis during design.
Analysis Objectives
Identify customers needs.
Evaluate system for feasibility.
Perform economic and technical analysis.
Allocate functions to system elements.
Establish schedule and constraints.
Create system definitions.
Software Requirements Analysis Phases
Problem recognition
Evaluation and synthesis
focus is on what not how
Modeling
Specification
Review
Management Questions

How much effort put towards analysis?


Who does the analysis?
Why is it so difficult?
Bottom line - who pays for it?

Feasibility Study
Economic feasibility
cost/benefit analysis
Technical feasibility
hardware/software/people, etc.
Legal feasibility
Alternatives
there is always more than one way to do it
System Specification
Introduction.
Functional data description.
Subsystem description.
System modeling and simulation results.
Products.
Appendices.
Software Requirements Elicitation
Customer meetings are the most commonly used technique.
Use context free questions to find out
customer's goals and benefits
identify stakeholders
gain understanding of problem
determine customer reactions to proposed solutions
assess meeting effectiveness
Interview cross section of users when many users are anticipated.
F.A.S.T. 1
Facilitated application specification technique
Meeting between customers and developers at a neutral site (no home advantage).
Goals
identify the problem
propose elements of solution
negotiate different approaches
specify preliminary set of requirements
F.A.S.T. 2
Rules for participation and preparation established ahead of time.
Agenda suggested
brainstorming encouraged
Facilitator appointed.

Definition mechanism
sheets, flipcharts, wallboards, stickers, etc.
Q.F.D. 1
Quality Function Deployment
Customers needs imply technical requirements:
Normal requirements
(minimal functional & performance).
Expected requirements
(important implicit requirements, i.e. ease of use).
Exciting requirements
(may become normal requirements in the future, highly prized & valued).
Q.F.D. 2
Function Deployment:
Determines value of required function.
Information Deployment:
Focuses on data objects and events produced or consumed by the system.
Task Deployment:
product behavior and implied operating environment.
Q.F.D. 3
Value Analysis makes use of:
Customer interviews.
Observations.
Surveys.
Historical data.
to create
Customer Voice Table
extract expected requirements
derive exciting req.
Analysis Principles
Information domain of problem must be presented & understood.
Models depicting system information, functions, and behavior should be developed.
Models and problems must be partitioned in a manner that uncovers detail in layers.
Analysis proceeds from essential information toward implementation detail
Must be traceable.
Information Domain
Encompasses all data objects that contain numbers, text, images, audio, or video.
Information content or data model
shows the relationships among the data and control objects that make up the
system
Information flow

represents manner in which data and control objects change as each moves
through system
Information structure
representations of the internal organizations of various data and control items
Modeling
Data model
shows relationships among system objects
Functional model
description of the functions that enable the transformations of system objects
Behavioral model
manner in which software responds to events from the outside world
Partitioning
Process that results in the elaboration of data, function, or behavior.
Horizontal partitioning
breadth-first decomposition of the system function, behavior, or information, one
level at a time.
Vertical partitioning
depth-first elaboration of the system function, behavior, or information, one
subsystem at a time.
Requirements Views
Essential view
Presents the functions to be accomplished and the information to be processed
while ignoring implementation
Implementation view
Presents the real world realization of processing functions and information
structures

4. Explain about requirement validation and management. (16)


Requirements Validation Objectives

Certifies that the requirements document is an acceptable description of the system to be


implemented
Checks a requirements document for
o Completeness and consistency
o Conformance to standards
o Requirements conflicts
o Technical errors
o Ambiguous requirements

Analysis and validation

Analysis works with raw requirements as elicited from the system stakeholders

o Have we got the right requirements is the key question to be answered at this
stage
Validation works with a final draft of the requirements document i.e. with negotiated and
agreed requirements
o Have we got the requirements right is the key question to be answered at this
stage

Validation inputs and outputs

Requirements
document

List of problems
Requ irements
validation

Organisational
knowledge

Agreed actions

Organisational
standards
Validation inputs

Requirements document
o Should be a complete version of the document, not an unfinished draft. Formatted
and organised according to organisational standards
Organisational knowledge
o Knowledge, often implicit, of the organisation which may be used to judge the
realism of the requirements
Organisational standards
Local standards e.g. for the organisation of the requirements document

Validation outputs
Problem list
o List of discovered problems in the requirements document
Agreed actions
o List of agreed actions in response to requirements problems. Some problems may
have several corrective actions; some problems may have no associated actions
Requirements reviews
A group of people read and analyse the requirements, look for problems, meet and
discuss the problems and agree on actions to address these problems
Requirements review process
Plan review

Distribute
documents

Prepare for
review

Hold review
meeting

Follow-up
actions

Revise
document

Review activities

Plan review
o The review team is selected and a time and place for the review meeting is
chosen.
Distribute documents
o The requirements document is distributed to the review team members
Prepare for review
o Individual reviewers read the requirements to find conflicts, omissions,
inconsistencies, deviations from standards and other problems.
Hold review meeting
o Individual comments and problems are discussed and a set of actions to address
the problems is agreed.
Follow-up actions
o The chair of the review checks that the agreed actions have been carried out.
Revise document
o The requirements document is revised to reflect the agreed actions. At this stage,
it may be accepted or it may be re-reviewed

Problem actions

Requirements clarification
o The requirement may be badly expressed or may have accidentally omitted
information which has been collected during requirements elicitation.
Missing information
o Some information is missing from the requirements document. It is the
responsibility of the requirements engineers who are revising the document to
discover this information from system stakeholders.
Requirements conflict
o There is a significant conflict between requirements. The stakeholders involved
must negotiate to resolve the conflict.
Unrealistic requirement
o The requirement does not appear to be implementable with the technology
available or given other constraints on the system.
Stakeholders must be
consulted to decide how to make the requirement more realistic.

Pre-review checking
Reviews are expensive because they involve a number of people spending time reading
and checking the requirements document
This expense can be reduced by using pre-review checking where one person checks the
document and looks for straightforward problems such as missing requirements, lack of
conformance to standards, typographical errors, etc.
Document may be returned for correction or the list of problems distributed to other
reviewers
Pre-review checking

Check document
structure

Check
document
completeness

Requirements
document

Check document
against
standards

Run
automatic
checkers

Problem report

Review team membership

Reviews should involve a number of stakeholders drawn from different backgrounds


o People from different backgrounds bring different skills and knowledge to the
review
o Stakeholders feel involved in the RE process and develop an understanding of the
needs of other stakeholders
Review team should always involve at least a domain expert and an end-user

Review checklists

Understandability
o Can readers of the document understand what the requirements mean?
Redundancy
o Is information unnecessarily repeated in the requirements document?
Completeness
o Does the checker know of any missing requirements or is there any information
missing from individual requirement descriptions?
Ambiguity
o Are the requirements expressed using terms which are clearly defined? Could
readers from different backgrounds make different interpretations of the
requirements?
Consistency
o Do the descriptions of different requirements include contradictions? Are there
contradictions between individual requirements and overall system requirements?
Organization
o Is the document structured in a sensible way? Are the descriptions of
requirements organized so that related requirements are grouped?
Conformance to standards
o Does the requirements document and individual requirements conform to defined
standards? Are departures from the standards, justified?
Traceability
o Are requirements unambiguously identified, include links to related requirements
and to the reasons why these requirements have been included?
-------------------------------****************************----------------------

Requirements Management

A systematic approach to
Eliciting
Organizing
Documenting
And managing
the changing requirements of a software project
Not a new concept!
Rational Approach to Requirements Management
Rational provides complete solution to requirements management
Rational Unified Process(RUP)
Recommends specific requirements management skills
Provides specific guidelines to effectively implement skills
Tools to automate these skills
RequisitePro, Rose, ClearCase
Requirements Management Skills
Six essential management skills:
Analyze the problem.
Understand the user needs.
Define the system.
Manage the scope of the system.
Refine the system definition
Manage the changing requirements
Requirements Management in RUP
Requirements management skills implemented in the requirements core-workflow
Considered workflows

Analyze the Problem

Purpose is to:
Gain an agreement on system features and goals
Develop Vision document for the project
The key artifacts produced in the workflow:
Vision document
Requirement management plan for the project
Glossary
Understand the User Needs
Purpose is to:
Collect information from the various stakeholders of the project
Use different elicitation techniques to elicit requests
The key artifacts produced in the workflow:
Refined vision document
Initial Use case model
Supplementary specifications
Refined glossary
Define the System
Purpose is to:
Ensure that all project team members understand the system
Perform high-level analysis on the results collected in previous workflows
Formally document results
The key artifacts produced in the workflow:
Refined vision document
Refined use case model
Refined Supplementary specifications
Refined glossary
Manage the Scope of the System
Purpose is to:
Define the set of requirements to be included in this version of the system
Define a set of architecturally-significant features and uses cases
Define attributes and traceability to help prioritize requirements
The key artifacts produced in the workflow:
Iteration plan
Refined vision document
Refined glossary
Refine the System
Purpose is to:
Provide a more in-depth understanding of the systems features
Provide detailed descriptions of use cases
Model and prototype user interfaces
The key artifacts produced in the workflow:

User-interface prototype
Detailed use case model
Revised iteration plan
Refined vision
Refined glossary
Manage Changing Requirements
Purpose is to:
Control and manage change
Set up appropriate requirements attributes and traceabilities

5. Explain Petri nets and data dictionary. (16)