UNIT 1 SOLUTIONS

2012 EXTERNAL PAPER

1. What is requirement engineering? How can the requirement engineering be improved?

Ans.

Requirements engineering (RE) refers to the process of formulating, documenting and

maintaining software requirements and to the subfield of Software Engineering concerned with
this process.

There are 4 steps of the requirement engineering:

Requirement elicitation
Requirement analysis
Requirement documentation
Review

Requirement elicitation: Requirements Gathering. This is asking what are the

requirements, what if this, what if that, etc. This is about asking the questions and getting
responses. How well are the answers is another matter entirely. This requires the stakeholders
to answer their part of what is to be done and why.

Requirement analysis: This is more the organizing of answers to the first part. Which
solution is optimal? What are the trade-offs of various possible implementations. In this part
there may be the odd question but it isn't the main point as this is about seeing which solution
may be better under various constraints, e.g. which is the fastest or cheapest. This is more
about how is something to be done and why does that way make more sense than another.

Requirement documentation: A set of documents provided on paper, or online, or on

digital or analog media, such as audio tape or CDs. The process of documenting knowledge,
as in scientific articles The process of providing evidence. The writing of product
documentation, such as software documentation. A synonym for the term document.

Review: It is a management study into a project's status and allocation of resources. It is

different from both a software engineering peer review, which evaluates the technical quality
of software products, and a software audit, which is an externally conducted audit into a
project's compliance to specifications, contractual agreements, and other criteria.

Steps to improve Requirement engineering::

 1. Define a standard document structure

2. Uniquely identify each requirement

3. Define policies for requirements management

4. Use checklists for requirements analysis

5. Use scenarios to elicit requirements

6. Specify requirements quantitatively

7. Use prototyping to animate requirements

8. Reuse requirements

2. Define the term software engineering. Explain the difference between software
engineering and other traditional engineering disciplines.

Ans. Software Engineering is the study and application of engineering to the design,
development, and maintenance of software.

Software engineering Other Traditional engineering

Software engineering is based on computer Traditional engineering is based on
science, information science and discrete mathematics, science and empirical
mathematics knowledge.
Software engineers construct non- Traditional engineers construct real artefacts.
real(abstract) artefacts.
Two main concerns are cost of development Two main concerns for a product are cost of
and reliability measured by the no. of errors production and reliability measured by time to
per thousand lines of source code. failure
Requires maintenance but in different ways. Requires maintenance but in different ways.
Software engineers often apply new and Traditional software engineers generally try to
untested elements in software projects. apply known and tested principles and limit the
use of untested innovations.
Software engineers emphasize projects that Traditional engineers solve long-ranged
will live for years or decades. problems that ensure for centuries.
Software engineering is often busy with Traditional engineering normally separates
researching the unknown right in the middle of these activities.
a project.
 3. Compare the waterfall model and the spiral model of software development.

Sol. The waterfall model

In this model, the software development activities move to the next phase only after the
activities in the current phase are over. However, like is the case with a waterfall, one cannot
return to the previous stage. The phases of this model are:

 Requirement Gathering and Analysis Phase

 Design Phase
 Coding Phase
 System Integration Phase
 Testing and Debugging Phase
 Delivery Phase
 Maintenance Phase

Advantages

1. There is minimum planning overhead for the steps that are to follow.
2. There is certain amount of discipline that is enforced as one has to only look into one
phase of the process at any given point of time.
3. The project does not slip on its schedule.
4. The number of resources working on the project does not keep on increasing with each
passing day, as the planning for the same is done at the start of the phase itself.
Disadvantages
1. The inability of making changes to the system, once the system requirements have been
frozen.

The spiral model

The spiral model was introduced, due to the shortcomings in the waterfall and prototype
models of software engineering. It is a combination of the said two models of software
development. From the name of the model, it can be derived that the activities of software
development are carried out like a spiral. To explain the model further, the entire software
development process is broken down into small projects. The phases of the spiral model are
as follows:

 Planning Phase
 Risk Analysis Phase
 Engineering Phase
 Coding and Implementation Phase
 Evaluation Phase

Advantages

1. It is a realistic model, which is often used in the development of large software.

2. There is a systematic approach used in the spiral model, which is integrated into the
iterative framework.
3. This helps in ensuring there is no problems in the software.
 4. Since changes to the software can be made at any point of time in the software
development process.

Disadvantages

1. The client may have to spend a lot of time with the development team to fix the
issues that have cropped up in the software
2. This also leads to the over involvement of the customer in the process of software
development

4. Explain in detail the prototype model. What are the advantage and disadvantage of
developing a prototype of a system.

Ans. In this model, it is assumed that all the requirements may not be known at the start of the
development of the system. This model allows the users to interact and experiment with a
working model of the system known as prototype. The prototype gives the user an actual feel of
the system.

At any stage, if the user is not satisfied with the prototype, it can be discarded and an entirely
new system can be developed. Using the prototype, the client can get an actual feel of the
system.

So, this case of model is beneficial in the case when requirements cannot be freezed initially.
This prototype is developed based on the currently known requirements.

1. Requirements gathering and analysis: A prototyping model begins with requirements

analysis and the requirements of the system are defined in detail. The user is interviewed in order
to know the requirements of the system.

2. Quick design: When requirements are known, a preliminary design or quick design for the
system is created. It is not a detailed design and includes only the important aspects of the
system, which gives an idea of the system to the user.

3. Build prototype: Information gathered from quick design is modified to form the first
prototype, which represents the working model of the required system.

4. User evaluation: Next, the proposed system is presented to the user for thorough evaluation
of the prototype to recognize its strengths and weaknesses such as what is to be added or
removed.

5. Refining prototype: Once the user evaluates the prototype and if he is not satisfied, the
current prototype is refined according to the requirements. That is, a new prototype is developed
with the additional information provided by the user. The new prototype is evaluated just like the
previous prototype. This process continues until all the requirements specified by the user are
met. Once the user is satisfied with the developed prototype, a final system is developed on the
basis of the final prototype.

6. Engineer product: Once the requirements are completely met, the user accepts the final
prototype. The final system is evaluated thoroughly followed by the routine maintenance on
regular basis for preventing large-scale failures and minimizing downtime.

Advantages

1. Provides a working model to the user early in the process, enabling early assessment and
increasing user's confidence.

2. The developer gains experience and insight by developing a prototype there by resulting in
better implementation of requirements.

3. The prototyping model serves to clarify requirements, which are not clear, hence reducing
ambiguity and improving communication between the developers and users.

4. There is a great involvement of users in software development. Hence, the requirements of

the users are met to the greatest extent.

5. Helps in reducing risks associated with the software.

Disadvantages

1. If the user is not satisfied by the developed prototype, then a new prototype is developed.
This process goes on until a perfect prototype is developed. Thus, this model is time
consuming and expensive.

2. The developer loses focus of the real purpose of prototype and hence, may compromise
with the quality of the software. For example, developers may use some inefficient
algorithms or inappropriate programming languages while developing the prototype.

3. Prototyping can lead to false expectations. For example, a situation may be created where
the user believes that the development of the system is finished when it is not.

4. The primary goal of prototyping is speedy development, thus, the system design can suffer
as it is developed in series without considering integration of all other components.
 5. Define DFD and ER diagram with example.

ANS.

Data Flow Diagrams

Data Flow Diagrams (DFD) helps us in identifying existing business processes. It is a technique
we benefit from particularly before we go through business process re-engineering.
At its simplest, a data flow diagram looks at how data flows through a system. It concerns things
like where the data will come from and go to as well as where it will be stored. But you won't
find information about the processing timing (e.g. whether the processes happen in sequence or
in parallel).
We usually begin with drawing a context diagram, a simple representation of the whole system.
To elaborate further from that, we drill down to a level 1 diagram with additional information
about the major functions of the system. This could continue to evolve to become a level 2
diagram when further analysis is required. Progression to level 3, 4 and so on is possible but
anything beyond level 3 is not very common. Please bear in mind that the level of detail asked
for depends on your process change plan.
Example ofData Flow Diagrams
entity–relationship diagrams

An ER model is an abstract way of describing a database. In the case of a relational database,

which stores data in tables, some of the data in these tables point to data in other tables - for
instance, your entry in the database could point to several entries for each of the phone numbers
that are yours. The ER model would say that you are an entity, and each phone number is an
entity, and the relationship between you and the phone numbers is 'has a phone number'.
Diagrams created to design these entities and relationships are called entity–relationship
diagrams or ER diagrams.