1. What is done in Requirement gathering & Analysis phase?

Requirement gathering:
 SDLC stands for software development life cycle is essentially a series of steps, or
phases, that provide a model for the development & lifecycle management of an
application or piece of software.
 Project manager & business organizations use the SDLC as a blueprint for completing
each step of the lifecycle for software development. Each step of the SDLC is called a
phase. The requirement gathering & analysis phase is the first phase of the SDLC.
 Requirement serve the detail descriptions of functions that software should provide.
Requirements specify need of client. Business analyst & subject experts are
responsible for requirement gathering process.
Requirement analysis:
 Gathering requirements for the project is the most important part of SDLC for project
managers & internal stakeholders of a project.
 During this phase the customer states the expectation of the project including who
will use the product, how the customer will use the product & the specific information
included with any special customer requirements related to the software.
 The customer meets with the business manager & analysts to provide requirements.
It’s important for the project team to understand the need of the customer because this
information is critical to developing the product the customer request.
 After the customer provides the requirements for the product, the project manager &
the members of the project team begin to analyse the requirements. The business
manager analyse each requirement to ensure the requirement can be included in the
software without causing breaks or problems with system functionality.

2. What do you understand by Implicit & Explicit requirements?

Implicit requirements:
 Implicit requirements are the hidden or assumed requirements.

 Business users expect these to be delivered & hence may not feel the need to
explicitly mention them in the business meetings.
 It could be challenging to actually define the scope as there is no clear-cut document
documentation or boundary available.
 For ex.: Login, filter process in amazon. Introducer is already holding an account with
the bank
 Explicit requirements:
 The requirement that are tested by the business users in the different meetings &
interviews are categorized as Explicit requirement.
 These retirements are the easiest to capture. They usually supported by loads of
documentation, or for that matter, even a legacy system screenshot.
 For ex.: user id, password.; in amazon multiple filters like style, size, colour etc.,
Account manager can create a new saving account. Introducer is required for creating
new account.

3. Explain the below requirements:

a. Correct requirements:

 Correctness in requirements is simply about getting it right. Writing requirements

correctly is as much about getting accurate information as it is about accurately
documentation the information we gather.
 Correctness applies in a context.
 No requirements in the model is wrong & thus every solution accepted by customer is
in accord with the model.

b. Unambiguous requirements:

 The requirements are concisely stated without recourse to technical jargon, acronyms
(unless defined elsewhere in the requirements document), or other esoteric verbiage.

 It expresses objective facts, not subjective opinions. It is subject to one & only one
interpretation. Vague subjects, adjectives, prepositions, verb & subjective phrases are
avoided. Negative statements compound statements are avoided.
c. Traceable requirements:

 The requirements meet all or part of a business need as stated by stakeholders &
authoritatively documented.

4.What do you understand by Functional & Non-Functional

Requirements?

Functional Requirements:
 A functional requirement defines a function of a system or its component. A function
is described as a set of inputs, the behaviour & 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. Behavioural requirements describing all the cases where the system uses
the functional requirements are captured in use cases.
 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.
 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 behaviour, which must
be clear and readable. The described behaviour may come from organizational or
business rules, or it may be discovered through elicitation sessions with users,
stakeholders, and other experts within the organization.

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 behaviours. They are contrasted with functional
requirements that define specific behaviour or functions.
 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-behavioural requirements".
 Qualities that is non-functional requirements can be divided into two main categories:
 Execution qualities, such as security and usability, which are observable at run time.

1.Evolution qualities, such as testability, maintainability, extensibility and

scalability, which are embodied in the static structure of the software system.

Examples:
A system may be required to present the user with a display of the number of records in a
database. This is a functional requirement. How up-to-date [update] this number needs to be,
is a non-functional requirement. If the number needs to be updated in real time, the system
architects must ensure that the system is capable of updating the [displayed] record count
within an acceptably short interval of the number of records changing.
Sufficient network bandwidth may be a non-functional requirement of a system.