Requirements analysis in systems engineering and software engineering, encompasses those

tasks that go into determining the needs or conditions to meet for a new or altered product,
taking account of the possibly conflictingrequirements of the various stakeholders, such as
beneficiaries or users.

equirements analysis is critical to the success of a development project.[

Requirements must be documented, actionable, measurable, testable, related to identified

business needs or opportunities,

equirements can be architectural, structural, behavioral, functional, and non-functional.

requirements analysis includes three types of activity:

 Eliciting requirements: the task of communicating with customers and users to determine
what their requirements are. This is sometimes also called requirements gathering.

 Analyzing requirements: determining whether the stated requirements are unclear,

incomplete, ambiguous, or contradictory, and then resolving these issues.

 Recording requirements: Requirements might be documented in various forms, such as

natural-language documents, use cases, user stories, or process specifications.

Analysts can employ several techniques to elicit the requirements from the customer.
Historically, this has included such things as holding interviews, or holding focus
groups (more aptly named in this context as requirements workshops) and creating
requirements lists

More modern techniques include prototyping, and use cases.

Where necessary, the analyst will employ a combination of these methods to establish the
exact requirements of the stakeholders, so that a system that meets the business needs is
produced.

Requirements engineering
Systematic requirements analysis is also known as requirements engineering.

It is sometimes referred to loosely by names such as requirements gathering, requirements

capture, orrequirements specification.

Requirements Engineering can be divided into discrete chronological steps:

 Requirements elicitation,
 Requirements analysis and negotiation,

 Requirements specification,

 System modeling,

 Requirements validation,

 Requirements management.

Functional requirement
From Wikipedia, the free encyclopedia

(Redirected from Functional requirements)

In software engineering, a functional requirement defines a function of a software system or

its component. A function is described as a set of inputs, the behavior, and outputs (see
also software).

Functional requirements may be calculations, technical details, data manipulation and

processing and other specific functionality that define what a system is supposed to
accomplish.

The plan for implementingfunctional requirements is detailed in the system design. The plan for
implementing non-functional requirements is detailed in the system architecture.

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.

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.
Non-functional requiremen
(Insystems 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.

In general, functional requirements define what a system is supposed to do whereas non-

functional requirements define how a system is supposed to be. Functional requirements are
usually in the form of "system shall <do requirement>", while non-functional requirements are
"system shall be <requirement>".

Knowledge areas
The business analysis body of knowledge defines 6 knowledge areas, which group together
related sets of tasks and techniques. Each of these tasks and techniques describes the typical
knowledge, skills, processes, and deliverables that the business analyst requires to be able to
perform those tasks competently.

While a flow of tasks and processes is suggested by these knowledge areas, the BABOK is
deliberately not setting out a prescribed methodology. Indeed, version 2.0 has separated
techniques from the knowledge area tasks, into a new section.
Business analysis planning and monitoring
how business analysts plan the tasks and activities for business analysis.
1. It covers stakeholder analysis,
2. selecting an approach to managing issues, risks and requirements;
3. deciding how to monitor and report on requirements activities; and
4. negotiating how to manage change on a project.
Elicitation
how business analysts work with stakeholders to help them understand their
requirements within the scope of a project. It covers eliciting
requirements; brainstorming; analysing documents; running focus groups; analysing
system interfaces; interviewing; observing; prototyping; facilitating
requirements workshops; reverse engineering existing systems; and collecting input
via surveys and questionnaires.
Requirements management and communication
how business analysts ensure that the project team and stakeholders stay in agreement
on project scope. It covers communicating requirements; resolving conflicts;
 gaining formal approval; baselining and tracking requirements through to
implementation.
Enterprise analysis
how business analysts take a business need: define that need; identify gaps in current
capabilities that stop that need being met; then if change is required, to propose an
approach and scope for finding a solution and building the case to justify the work. It
explores assessing business architecture; undertaking capability gap analysis; feasibility
studies; defining the solution scope; and developing a business case.
Requirements analysis
how business analysts work with the whole project team towards defining a solution that
should meet the agreed requirements. It covers documenting and
analysing business,stakeholder, functional, and non-functional (quality of service)
requirements; modelling the business domain using process diagrams, flowcharts, data
models; exploring behaviour models using use case, user experience
design, storyboards, wireframes, user profiles and user stories; and finally verifying and
validating requirements.
Solution assessment and validation
how business analysts assess proposed solutions to help the stakeholders select the
solution which best fits their requirements, and once selected how the business should
prove that the solution meets those requirements and ultimately whether the project has
met its objectives. It covers evaluating alternate solutions, quality assurance
processes, supportthrough implementation, and post-implementation reviews.
Underlying competencies
covers the leadership, problem solving, and communication skills; business and
technical knowledge that support effective business analysis.
Techniques
defines a range of specific skills, methods, and tools that enable the business analysis
tasks in the six knowledge areas - there are 34 techniques listed in
the Techniques section, with a further 15 defined within the knowledge areas.

Requirement elicitation :

Requirements elicitation is non-trivial because you can never be sure you get all requirements
from the user and customer by just asking them what the system should do. Requirements
elicitation practices include interviews, questionnaires, user observation, workshops,
brain storming, use cases, role playing and prototyping.

Verification Phases
[edit]Requirements analysis
In the Requirements analysis phase, the requirements of the proposed system are collected by
analyzing the needs of the user(s). This phase is concerned about establishing what the ideal
system has to perform. However it does not determine how the software will be designed or
built. Usually, the users are interviewed and a document called the user requirements
document is generated.

The user requirements document will typically describe the system’s functional, physical,
interface, performance, data, security requirements etc as expected by the user. It is one which
the business analysts use to communicate their understanding of the system back to the users.
The users carefully review this document as this document would serve as the guideline for the
system designers in the system design phase. The user acceptance tests are designed in this
phase. See also Functional requirements. this is parallel processing
[edit]System Design
Systems design is the phase where system engineers analyze and understand the business of
the proposed system by studying the user requirements document. They figure out possibilities
and techniques by which the user requirements can be implemented. If any of the requirements
are not feasible, the user is informed of the issue. A resolution is found and the user
requirement document is edited accordingly.

The software specification document which serves as a blueprint for the development phase
is generated. This document contains the general system organization, menu
structures, data structures etc. It may also hold example business scenarios, sample
windows, reports for the better understanding. Other technical documentation like entity
diagrams, data dictionary will also be produced in this phase. The documents for system testing
are prepared in this phase.
[edit]Architecture Design
The phase of the design of computer architecture and software architecture can also be referred
to as high-level design. The baseline in selecting the architecture is that it should realize all
which typically consists of the list of modules, brief functionality of each module,
their interface relationships, dependencies, database tables, architecture diagrams, technology
details etc. The integration testing design is carried out in the particular phase.
[edit]Module Design
The module design phase can also be referred to as low-level design. The designed system is
broken up into smaller units or modules and each of them is explained so that the programmer
can start coding directly. The low level design document or program specifications will contain a
detailed functional logic of the module, in pseudocode:

 database tables, with all elements, including their type and size

 all interface details with complete API references

 all dependency issues

 error message listings

 complete input and outputs for a module.

The unit test design is developed in this stage.

V model

Use Case. A use case defines a goal-oriented set of interactions between external actors and the system under
consideration.
That is, use cases capture who (actors) does what (interactions) with the system, for what purpose
(goal). A complete set of use cases specifies all the different ways to use the system, and thus defines all
behavior required of the system--without dealing with the internal structure of the system.
Requirements for the requirements

Gathered requirements must be a

1. Specific
2. Unambiguous
3. Verifiable
4. Quantifiable
5. Measurable
6. Complete
7. Traceable
8. Accessible
9. Understandable
Low threshold

process which fulfills these requirements is from

technical point of view sound and robust

JAD SESSION
JAD (Joint Application Development) is a methodology that involves the client or end user in the
design and development of an application, through a succession of collaborative workshops
called JAD sessions.

ADVANTAGE; SHORTNING OF THE TIME

IMPROVE THE QUALITY OF THE FINAL PRODUCT BY FOCUSING THE
UPFRONT PORTION OF THE DEVELOPMENT LIFE CYCLE,
REDUCING THE LIKEHOOD OF ERRORS, THAT EXPENSIVE TO CORRECT IT LATER ON.

SOFTWARE TESTING ; Software testing is the process to identify the correctness,

completeness and quality of the software that developed, it include the set of activities that
intent to find out the error in the software, so it could be corrected before it release to the end
users.
That means, software testing is the activity to check whether the actual results match the
expected results, and to ensure the final software system is error free.
What is your strength as BA

Well, I have been working as ba for last 4 years, so for me my past experience is my
biggest strength, moreover that I have a mixing of functional and technical knowledge,
That help me to communicate effectively between users and development team,
Quick learning capability, and adaptability of the work environment as desired,

Describe the term black box testing.

The black box testing is the type of testing whereby the entire unit is tested as whole
without considering contents or even how the inner components of the units work under
test work. The testers only consideration is to enter a known input signal and check
whether the output behavior is one expected or not.

What is SDLC

Sdlc is stand for software development life cycle, is the process to develop the new
system or software, it comprises different phases, like planning, requirement capturing,
design, coding, testing, release and maintainance

In planning phase feasibility study is conducted and determine the scope of the project
to be success.
Requirement capturing, main functional area of the business analyst, where he capture
the business requirements by interviewing the stakeholders, users, consumers, research
and analysis of the current working system.
Design phase architecture make the design by using the uml methodology, and figure
out the possibilities and technique by which the users requirements is implemented, and
if any requirements is unfeasible, they informed the business analyst, and resolutions is
found and informed to ba and user requirements documents is edited accordingly,

The software specification documents which serve as a blue print for the development
phase which is generated. This documents contain the general system organization,
menu structure, data structure, etc. the documents for the system testing is done in this
phase.

Coding phase, developer coding the system by using the software specification
documents, and system is developed

Testing phase, this is the process to test the correctness, completeness and quality of
the software that has been developed, it include the set of the activities to find out the
error , that could be corrected before it release to users

Release if testing phase clear the software bug free,

Maintainace. Once the system is implemented in live condition , it has to maintained

well.software may face the changes in future because of the unexpected inputs or
change by the new personnel in organization, so any problem arising need to be fix to
maintain the system well.]
Give the importance of the using flow charts.
Flow chart is the diagrammatic representation of the flow of information, it makes easy to
understand the text information for all vitals person like developers, users, ba and tester

Good requirements start with the context of the business and its processes and
address what the business is trying to achieve, rather than focusing on how the
goals will be accomplished.

For example, in dealing with something as complex as customer order

management, it is necessary to break it down into steps like “receive a call from a
customer.” That is the first step in the process. For each and every step there
should also be a high-level description that must also include detail for associated
process steps. Each of those process steps should be detailed enough that it is easy
to extract from them how information moves among stakeholders and the systems
within the enterprise.
It

Requirements Quality Checklist:

The requirements document is not overly technical or complicated
The requirements document starts with the context of the business and its
processes
The process is broken down into steps
Each step includes a high-level description
Process steps are detailed enough that it is easy to extract how information moves
among stakeholders and the systems within the enterprise
Care was taken in the production of the document

What’s the quality of the objectives?

The fourth step in evaluating requirements is to look at the quality of
objectives.. Be sure that objectives are actually SMART - Specific,
Measurable, Achievable, Relevant, and Time-bound. If there is not
progression in subsequent iterations of documentation, there is a problem.

A use case is a sequence of actions that provide a measurable value to an actor.

Requirement specification
• Easily misunderstood
• Too large to comprehend
• Hard to test for completeness
• Provide no context

Why use cases

• The hard part: Build the right thing
• Describes behavior of the system
 • Easily understood by
– Problem-oriented stakeholders
– Solution-oriented stakeholders
• Focus on actual system needs

What is actor

• A role, not a person

• Human or non-human
• Three essential traits
– External to the system
– Interacts with the system
– Tries to achieve a goal
What is use case

• Describes one way to use the system

• Essential traits:
– Centered around a goal
– Describes steps to achieve that goal
– Written as a series of interactions
– Yields a result to the actor
•
• When writing the flow of events, focus on the
interactions between the actors and the system. The
purpose of the flow of events is to clearly define the
responsibilities of both the actors and the system at
each step in the interaction.
• This is often called the Main Success Scenario and
describes the flow of events when nothing goes
wrong. Later we will see how to show exceptions and
alternatives to the MSS by using extensions.

In this presentation you have seen that use case modeling

increases the likelihood of project success by:
• Developing a shared vision (are we building the
right thing? are we building the same thing?)
• Bridging the gap between problem-oriented
stakeholders and solution-oriented stakeholders
 • Providing advantages over traditional
requirements specifications
• Focusing on the users’ needs
In addition you should have a basic understanding of what
actors and use cases are and how they are developed:
• Actors have goals. Use cases describe the details
of those goals.
• Use cases are developed iteratively
• The main success scenario of the use case
describes the flow of events when nothing goes
wrong
• Alternatives and exceptions to the main success
scenario are specified using exceptions
• Identifying exceptions early on is one of the
great benefits of use case modeling

What is a UML Use Case Diagram (UCD), and when should I use it?
UML Use Case Diagrams can be used to describe the functionality of
a system in a horizontal way. That is, rather than merely
representing the details of individual features of your system, UCDs
can be used to show all of its available functionality. It is important
to note, though, that UCDs are fundamentally different from
sequence diagrams or flow charts because they do not make any
attempt to represent the order or number of times that the systems
actions and sub-actions should be executed. There are a number of
graphical examples in this FAQ; you might want to look over them to
familiarize yourself with the look of them.

UCDs have only 4 major elements: The actors that the system you
are describing interacts with, the system itself, the use cases, or
services, that the system knows how to perform, and the lines that
represent relationships between these elements.

You should use UCDs to represent the functionality of your system

from a top-down perspective (that is, at a glance the system's
functionality is obvious, but all descriptions are at a very high level.
Further detail can later be added to the diagram to elucidate
interesting points in the system's behavior.)
Example: A UCD is well suited to the task of describing all of the
things that can be done with a database system, by all of the people
who might use it (administrators, developers, data
entry personnel.)

You should NOT use UCDs to represent exception behavior (when

errors happen) or to try to illustrate the sequence of steps that must
be performed in order to complete a task. Use Sequence diagrams
to show these design features.
Example: A UCD would be poorly suited to describing the TCP/IP
network protocol, because there are many exception cases,
branching behaviors, and conditional functionality (what happens
when a packet is lost or late, what about when the connection
dies?)

Back to top

How do you know who the actors are in a UCD?

When working from an Action/Response table, itentifying the actors
is easy: entities whose behavior appears in the "Actor's Actions"
column are the actors, and entities whose behavior appears in the
"System's Response" column are components in the system.

If you are working from an informal narrative, a sequence diagram,

or a scenario description, the actors are typically those entities
whose behavior cannot control or change (i.e., agents that are not
part of the system that you are building or describing.) The most
obvious candidates for actors are the humans in the system; except
in rare cases when the system you are describing is actually a
human process (such as a specific method of dealing with customers
that employees should follow) the humans that you must interact
with will all be actors. If your system interacts with other systems
(databases, servers maintained by other people, legacy systems)
you will be best to treat these as actors, also, since it is not their
behavior that you are interested in describing.
Example: When adding a new database system to manage a
company's finances, your system will probably have to interface
with their existing inventory management software. Since you didn't
write this software, don't intend to replace it, and only use the
services that it provides, it makes sense for that system to be
an actor.

Back to top

How do you know what to put in the "System" box?

The system box only appears on the top-level diagram (remember
that a typical UML Use Case description will be composed of many
diagrams and sub-diagrams), and should contain use case ovals,
one for each top-level service that your system provides to its
actors. Any kind of internal behavior that your system may have
that is only used by other parts of the system should not appear in
the system box. One useful way to think of these top-level services
is as follows: if a use case represents a top-level service, then it
should make sense for the actors who interact with it to
request only that service of your system in a single session (in
whatever sense a "session" is intelligible in your system.)

Example: In the diagram below we would like to represent the use

cases for a camera. Suppose we choose "Open Shutter", "Flash",
and "Close Shutter" as the top-level use cases. Certainly these are
all behaviors that a camera has, but no photographer would ever
pick up their camera, open the shutter, and then put it down,
satisfied with their photographic session for the day. The crucial
thing to realize is that these behaviors are not done in isolation, but
are rather a part of a more high-level use case, "Take Picture".
(Note that it does make sense for a photographer to "Take Picture"
just once during a session with their camera.)

Back to top

The actors in my diagram have interactions. How do I represent them?

If there are interactions between the actors in your system, you
cannot represent those interactions on the same diagram as your
system. What you can do instead is draw a separate UCD, treating
one of the actors itself as a system, and your original system (along
with the other actors) as actors on this new diagram.

Example: Suppose you wanted to diagram the interactions between

a user, a web browser, and the server it contacts. Since you can
only have one system on the diagram, you must choose one of the
obvious "systems", such as the server. You might then be tempted
to draw interaction lines between the actors, but this is a problem
because it isn't clear what the interaction means, so it isn't helpful
to show it here. A more useful solution would be to draw two
diagrams, showing all of the interactions, as below.
Back to top
I am trying to represent a sequence of actions that the system performs.
How do I do it?
Using a UML Use Case Diagram, you can't. UCDs are meant to be a
top-down, horizontal description of functionality, not a blow-by-blow
desrciption of behavior. For the most part, it isn't a good idea to try
to represent sequences of actions with Use Case diagrams. You
should use a Sequence Diagram or a traditional flow chart instead.
(It is possible to represent simple branching conditions with a UCD,
as described below, but you should use this technique sparingly
because it can render a diagram unreadable.)

Back to top

How is a UML Use Case Diagram different from a traditional flow chart?
As mentioned above, UCDs represent functionality in a top-down
way, whereas flow charts represent behavior in a linear, time-based
way. Also, the way you develop them is all-together different.

Example: (This text refers to the diagrams below.) When

constructing a UCD, the initial step is to identify all of the top-level
behavior. Once you have done this (not a very tricky process) you
have already described, at least in a high-level way, all of the things
your system knows how to do. You can then continue to add detail
by decomposing your use cases into more use cases which
are used by the top-level use cases. At every stage of development,
though, your UCD is a complete description of the system's
functionalty: it may lack detail, but it will not lack feature set
elements. And if functionality or behavior is added or deleted over
the life of your project, the scope of the change you need to make is
proportional to both the scope of the change in the system itself,
and the maturity of your model. This is useful because it means that
when your model is very young (only high-level diagrams drawn)
making sweeping changes to the system does not involve throwing
very much work away. A flow chart, however, does not correctly
describe the system until you have finished drawing it, and even
then small changes in the system will result in significant reworking
of your flow charts. In general, UCDs support the process of analysis
and design much better than flow charts.
Back to top

When do I use the uses arrow?

The uses arrow (or uses edge as it would be called in traditional
graph thoery) is drawn from a use case X to another use case Y to
indicate that the process of doing X always involves doing Y at least
once (although it may involve doing it many times, "at least once" is
the only relationship guaranteed by this symbol.) This symbol can
be referred to as an aggregation operator, because it indicates that
a given use case is an aggregate (made up of parts) whose
components are the use cases that it uses. If a certain use
case uses several others, that means that all of the component use
cases must be completed in the process of completing the
aggregate use case, although there is no specification in UCDs of
the order in which these are completed. A brief, mnemonic way to
think about the uses arrow is that it it can be read X uses Y means
that "X has a Y" as part of it's behavior.

Example: Suppose you wanted to add detail to the diagram shown

below, representing an airline reservation system. First, you would
create a separate diagram for the top-level services, and then you
would add new use cases that make up the top-level ones. There is
a uses edge from "Check in Passenger" to "Weigh Luggage" and
from "Check in Passenger" to "Assign Seat"; this indicates that in
order to Check in a Passenger, Luggage must be Weighed and a
Seat must be Assigned. Similarly, the diagram indicates that in order
to add a reservation to the system, the available space must be
checked and the passenger's information must be recorded. You
could imagine breaking these use cases down further to show more
detail.
Back to top
When do I use the extends arrow?
The extends arrow (or extends edge) is drawn from a use case X to
a use case Y to indicate that the process X is a special case behavior
of the same type as the more general process Y. You would use this
in situations where your system has a number of use cases
(processes) that all have some subtasks in common, but each one
has something different about it that makes it impossible for you to
just lump them all together into the same use case.

Example: Suppose you wanted to add detail to the diagram shown

below, representing an airline reservation system. Specifically, what
you would like to show is that not all of the seats aboard the
airplane are exactly alike (some window and some aisle seats), and
sometimes passengers will express a preference for one of these
types of seats but not the other. But of course, they cannot just be
given their preference right away, because the seat they want might
not be available. Therefore, the process of assigning a window seat
involves checking for the availability of window seats, whereas the
process of assigning an aisle seat involves checking for the
availability of aisle seats. But even though these processes are
different, they are quite similar in a number of other ways, so it
doesn't make sense to ignore their similarities. Fortunately, UML lets
us have both: we write that assigning these two types of seats are
different processes, but they are similar in that both
processes extend a common, more general process (assigning
seats.)
Back to top

What is the difference between uses and extends?

Probably the best way to think about these diagram elements is as
follows:

- "X uses Y" indicates that the task "X" has a subtask "Y"; that is, in
the process of completing task "X", task "Y" will be completed at
least once.
- "X extends Y" indecates that "X" is a task fo the same type as "Y",
but "X" is a special, more specific case of doing "Y". That is, doing X
is a lot like doing Y, but X has a few extra processes to it that go
above and beyond the things that must be done in order to
complete Y.

Example:indicates that inorder to successfully "Check-in", you must

"Weigh luggage" and "Assign a seat", some number of times, in
some order. The key, though, is that all UCs used by a use case
MUST BE DONE before that use case be considered to be complete.
Once you realize that there are several types of seat assignment,
you might be tempted to draw a diagram using the uses edge like
the one below, but this doesn't make sense: This diagram says that
in order to assign a seat you must assign both a window seat AND
an aisle seat to the passenger. Never fear, however; this situation is
correctly handled by the extends relationship. Using
the extends relationship (as shown in the following diagram), we
can express that there are two ways to assign a seat: assigning a
window seat and assigning an aisle seat, but only one need be
completed in the process of assigning the passenger a seat.