INTERVIEW QUESTIONS

Q& A for F-MAC

1.) How will u go ahead in gathering requirements?
Sol.) I make sure that the project scope is clear and complete before I can begin actual detailed requirements
gathering.
In some of the projects, Sometimes the scope was defined by the project sponsor or manager or by stake holders for
some projects but I was responsible for defining and documenting the scope as part of the requirements gathering
task in my last project.
In that case I started with creating high level vision document before actually defining the scope of the project.

For creating vision document
* I interviewed the business users to determine functional requirements of the software system
* Analyze interview results to identify NFRs, risks, and constraints
* Create a project Vision document from the results of the interviews and risk analysis

My role as Defining and documenting the project scope started with
(i) Why the project has been initiated (project statement of purpose) and
(ii) The goals of the project (project objectives).
(iii) Names of all the organizations that will be involved with the project; this included people, systems, internal
departments, and outside organizations (project external interactions).
(iv)Other important components of the project scope documentation included the project viewpoint, project
assumptions, and business risks.

The project scope should include a high-level description of the business processes that will be included.

It sometimes also includes a list of items that specifically will not be included in the scope. This gives the entire
project team a complete understanding of the work that I will be doing as we move into detailed requirements
gathering.

These components gave me the information necessary to prioritize and focus their requirements gathering.

I use to elicit the Requirements through various activities such as interviewing, brainstorming, conceptual
prototyping, and using questionnaires.

The result of requirements elicitation is a list of requests or needs that are described textually and graphically and
that have been given priority relative to one another.

We used to gather user input during application development in a number of ways: -
*surveys (usually for large organizations);
*on-site workflow observation;
*one-on-one user interviews;
*focus group, multiple-user sessions;
* or combinations and variations of all of these.
The Main Goal was to - Understand the business process.

2.) What r the barriers u faced in gathering requirement?

(i) The users were usually busy with their regular activities so they usually didnt have time to interview.
Sol. So thats the reason I used to send a questionnaire to the users before actually meeting them.

(ii) When we talk to users there is an interception or perception problems
Sol. So I used to involve SME while gathering requirements to solve the interception problem.

(iii) Some users have attitude problems so as a Business analyst I should be able to deal with all types of users.

(iv) Some other possible barriers can be like understanding the system initially or gaining the
domain knowledge. So understanding the system initially can be one of the possible barriers
Sol. So I used to talk to the SME and read lot of documentation.

/*While gathering requirements for a replacement to an aging database application in which I was involved in
designing, I had difficulty getting users to constructively criticize the old system. They knew I had designed it and
felt obliged to talk about how good it was, thinking I was there to defend my earlier work. Users need to know that
all software has a life cycle and is eventually replaced as user needs change and evolve.*/

If youre working on enhancing an existing system, make sure users understand that you need to know how to
preserve the best features of existing software, while at the same time eliminating or improving on features that are
not working properly.

3.) How did u over come it?
Answers are stated above

4.) You had talked about a JAD sessions. Were you comfortable just attending them or did you facilitate
them?
See usually one approach that we followed of finding use cases was by interviewing the potential users of the
system. (There can be ambiguity in this case)
So we have JAD sessions. We had sessions called Joint requirements planning workshops (JRP).
These workshop pulled people together a group of people interested in the system being developed (basically the
stake holders).
Everyone one in the group was invited to give their view of what the system needs to do. And yah Key to success of
these workshops is the facilitator.
Yah as a facilitator I used to lead the group, ensuring the discussion sticks to the point and all stake holders are
encouraged to put their views across.
A scribe is also present, ensuring everything is documented.
A simple method of attacking a workshop is
(i) Brainstorming all possible actors first
(ii) Brainstorming all possible use cases
(iii) Justifying each use case by a simple one paragraph document
(iv) Capture them on the model
Again Conceptual modeling (Domain modeling) is the activity of finding out which concepts are important to our
system.


Clear quest for defect tracking and enhancement requests

Ppl to invite in JAD session:

BA , SA ,developer , tester , PM


Q1). How do you document requirements?
A- After I finish all the user meetings, interviews, JAD sessions, I will generally take notes. After finishing
requirement-gathering sessions, I will organize the requirements and put them into requirement document templates.
Then these templates can be sent to the users for the user review. Once the user approves it, we can send this
document to the project folder.
Q2). How do you come up with functional specification document?
A- It is a blueprint for like how we want a particular project or application to look and work. It also details
what the finished product will do and how a user will interact with it. It is in essence a contract between the
business customer and the IT project team, describing from a technical view what the customer expects.
B- We can develop this document using use case document and information from the stakeholders. Contents-
1) Introduction- project overview, purpose, scope, assumptions, business process flow (existing and
required), project reference, audience, glossary of terms, stakeholders. 2) Users and roles- internal business
users, customer and clients, vendors. 3) Requirements- key assumptions dependencies, open issues. 4)
Stakeholders signup.

Q3). How do you collect requirements?
A- I would start with reading the scope and the vision document. I would meet a broad range of users and will
understand their requirements. Facilitating discussion sessions between the stakeholders of the project, Conduct one
to one user requirement sessions between the key users and the business manager, Conduct JAD (Joint Application
Development) workshops

Q4). What is a business process model?
A- It defines the following elements- the goal or reason for the process, specific inputs, specific outputs, resources
consumed, activities that are performed in some order and events that drive the process.

Q5). What is the most challenging thing that you faced?
A- Meeting user expectations. On the delivery of the project, the user might be expecting more. In a multi release,
all users want their features to go in the first release.

Q6). How do you manage user expectations?
A- Managing user expectations is one of the major challenges that I came across during my project. We have
to make sure that users do not immediately expect 100% accuracy and completeness from the application
when we go live. The best thing to do would be to start with functional areas that we know are valid and
complete. The user expectations can be met by conducting review meetings at the end of requirement
phase, documenting the reviewed requirements in the review document, getting the approval from user
managers, keep the user and the managers updated with the latest status of reviewed requirements, in case
any feature was missed out or a new feature is to be added in the system or in other words, the scope of the
project changes, then we can work out with the project manager and fill the change request form.



Q7). How do you conduct user meetings?
A- We can plan the user meetings ahead of time and send meeting invitations to the users with the agenda of the
meeting, location, time and the topic that will be discussed in the meeting. During the meeting, we can take down
document minutes, which will help us to identify who said what during the meeting. During the meeting, we can
also document the issues resolved and the issues that are not resolved. For any resolved issue, we can identify the
owner of that issue who will help in solving them. All the business managers have to be presented with the question
list if they lie in the scope of the project. Then they are asked the time according to their convenience and finally the
meeting can be arranged.

Q8). Have you ever worked with the management?
A- Yes, I have worked with the top-level management at many different occasions. 1) During the requirement-
gathering phase, I had the opportunity to do 1 on 1 interview with the business managers. 2) Kept good
communication with the management during the project phase. 3) Whenever there were any issues, I worked with
the project manager to resolve the issues. 4) I also had a chance to interact with the managers during the requirement
and project review meetings. 5) I made project presentations to senior management during project review meetings.
Q9). How do you know you have collected the right requirements?
A- We can document all the requirements that we have collected. We can then send them to the users for the user
review at the end of each meeting. We can review questions with the user managers and get their approval on the
review document.
Q10). How do you decide which iteration contains what features?
A- Since everyone wants their features to be released in the 1
st
iteration or the 1
st
release, it could be decided on the
A) Business priority: like what feature should go first based on the scope document. We can also get together with
business managers and discuss with them what they require in the first release and get their approval. B) Business
complexity: We can study the business complexity and decide what feature should come in what release changes.