1)What are Software practices?

Software practices are specific things you do as part of the software

development process.
That is, practices are activities that implement the process
Software development practices that might take place in each phase
below
A software process defines the steps you take develop (good)
software
A software process typically defines phases (or stages) and steps you
take within each phase to develop (good) software
1.1) Explain the phases in SDLC?

What is SDLC?
SDLC is a process followed for a software project, within a software organization. It
consists of a detailed plan describing how to develop, maintain, replace and alter or
enhance specific software. The life cycle defines a methodology for improving the
quality of software and the overall development process.
The following figure is a graphical representation of the various stages of a typical
SDLC.

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is
performed by the senior members of the team with inputs from the customer, the
sales department, market surveys and domain experts in the industry. This
information is then used to plan the basic project approach and to conduct product
feasibility study in the economical, operational and technical areas.
Planning for the quality assurance requirements and identification of the risks
associated with the project is also done in the planning stage. The outcome of the
technical feasibility study is to define the various technical approaches that can be
followed to implement the project successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and
document the product requirements and get them approved from the customer or
the market analysts. This is done through an SRS (Software Requirement
Specification) document which consists of all the product requirements to be
designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best architecture for
the product to be developed. Based on the requirements specified in SRS, usually
more than one design approach for the product architecture is proposed and
documented in a DDS - Design Document Specification.
This DDS is reviewed by all the important stakeholders and based on various
parameters as risk assessment, product robustness, design modularity, budget and
time constraints, the best design approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along
with its communication and data flow representation with the external and third party
modules (if any). The internal design of all the modules of the proposed architecture
should be clearly defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The
programming code is generated as per DDS during this stage. If the design is
performed in a detailed and organized manner, code generation can be
accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and
programming tools like compilers, interpreters, debuggers, etc. are used to generate
the code. Different high level programming languages such as C, C++, Pascal, Java
and PHP are used for coding. The programming language is chosen with respect to
the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the
testing activities are mostly involved in all the stages of SDLC. However, this stage
refers to the testing only stage of the product where product defects are reported,
tracked, fixed and retested, until the product reaches the quality standards defined
in the SRS.
Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the
appropriate market. Sometimes product deployment happens in stages as per the
business strategy of that organization. The product may first be released in a limited
segment and tested in the real business environment (UAT- User acceptance
testing).
Then based on the feedback, the product may be released as it is or with suggested
enhancements in the targeting market segment. After the product is released in the
market, its maintenance is done for the existing customer base.

2) List different Software Engineering Tools and explain each of them?

Read Slide

3) Explain different Software Engineering Methods?

Methods usually provide a notation and vocabulary, procedures for

performing identifiable tasks, and guidelines for checking both the
process and the product
These are categorized as

• Heuristic methods
dealing with informal approaches.

• Formal methods
dealing with mathematically based approaches.

• Prototyping methods
dealing with software engineering approaches based on
various forms of prototyping

Heuristic Methods
These are categories as
Structured methods
The system is built from a functional viewpoint, starting with a high-level view and
progressively refining this
into a more detailed design.
Data-oriented methods
The starting points are the data structures that a program manipulates rather than the
function it performs
Object-oriented methods
The system is viewed as a collection of objects rather than functions
Domain-specific methods
Includes specialized methods for developing systems which involve real-time, safety,
or security aspects
Formal Methods
These are categorized as
Specification languages and notations
This topic concerns the specification notation or language used. Specification
languages can be classified as model-oriented, property-oriented, or
behavior-oriented
Refinement
This topic deals with how the method refines (or transforms) the specification

into a form which is closer to the desired final form of an executable program .
Verification/Proving properties:
This topic covers the verification properties that are specific to the formal
approach, including both theorem proving and model checking
Prototyping Methods
These are categorized as
Prototyping styles
The prototyping styles topic identifies the various approaches: throwaway,
evolutionary, and
executable specification
Prototyping targets
Examples of the targets of a prototyping method may be requirements, architectural
design, or the user interface
Prototyping evaluation techniques
This topic covers the ways in which the results of a prototype exercise are used
4) What is SRS? Explain the requirements classification?

A software requirements specification (SRS) is a document that captures complete

description about how the system is expected to perform. It is usually signed off at
the end of requirements engineering phase.

Qualities of SRS:
Correct
Unambiguous
Complete
Consistent
Ranked for importance and/or stability
Verifiable
Modifiable
Traceable
A software requirement can be of 3 types:
 Functional requirements
 Non-functional requirements
  Domain requirements

Functional Requirements: These are the requirements that the end user

specifically demands as basic facilities that the system should offer. All these
functionalities need to be necessarily incorporated into the system as a part of the
contract. These are represented or stated in the form of input to be given to the
system, the operation performed and the output expected. They are basically the
requirements stated by the user which one can see directly in the final product, unlike
the non-functional requirements.
For example, in a hospital management system, a doctor should be able to retrieve the
information of his patients. Each high-level functional requirement may involve
several interactions or dialogues between the system and the outside world. In order to
accurately describe the functional requirements, all scenarios must be enumerated.
There are many ways of expressing functional requirements e.g., natural language, a
structured or formatted language with no rigorous syntax and formal specification
language with proper syntax.
Non-functional requirements: These are basically the quality constraints that the
system must satisfy according to the project contract. The priority or extent to which
these factors are implemented varies from one project to other. They are also called
non-behavioral requirements.
They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
NFR’s are classified into following types:
  Interface constraints
 Performance constraints: response time, security, storage space, etc.
 Operating constraints
 Life cycle constraints: mantainability, portability, etc.
 Economic constraints
The process of specifying non-functional requirements requires the knowledge of the
functionality of the system, as well as the knowledge of the context within which the
system will operate.
Domain requirements: Domain requirements are the requirements which are
characteristic of a particular category or domain of projects. The basic functions that a
system of a specific domain must necessarily exhibit come under this category. For
instance, in an academic software that maintains records of a school or college, the
functionality of being able to access the list of faculty and list of students of each
grade is a domain requirement. These requirements are therefore identified from that
domain model and are not user specific

6)Briefly explain the benefits of Requirement Management

tool?
Requirements management tool supports the analyst in documenting project
requirements, versioning requirements, managing the requirement change process,
tracing requirements through the analysis and design process, and tracking the status
of requirements.
Some examples of requirement management tools are:
Enterprise Architect, Requisite Pro, Telelogic, Caliber-RM
Page 16 cahpter 2 slide

7) Write the selection criteria for choosing Requirement Management

tool?
Whatever you use, there are some main functions that any requirements
tool has to fulfill.
• Serve as a point of reference to document a project’s requirements and
implementation
• Serve as a blueprint to help stakeholders understand what to expect out of the
project
By and large, there’s a huge range of features offered in requirements
management tools
• including modules for product management
• portfolio management
• release management
• customer management
8)What is traceability? How do you generate traceability report using ReqView tool?