Anda di halaman 1dari 5

Once upon a time, there was a business analyst named Tristan.

He made a one year contract


with Rave, a fish vendor, to make a software that will automate fish selling. Rave is a high-school
graduate so Tristan should speak only Tagalog so that Rave can understand him. Tristan is a rich man,
he is not familiar how people sell and buy fish in the wet market. In order to make a software that can
serve Rave, he must go to the marketplace and observe Rave while selling fish so that he can learn
about the fish-selling business. While Rave is busy selling the fish to hundreds of customers, Tristan is
busy recording and organizing requirements in an appropriate form wherein Rave can easily
understand. Evening fell and it was closing time, Rave still has a basket of fish that were left unsold.
Tristan comforted Rave and they talked about how the automated fish selling process would go. Tristan
handed a software requirements diagram and explained the deliverable to Rave. There were a lot of
ideas that Rave has thought as he read the document so he asked Tristan if he could change the
requirements. Tristan nodded and smiled. Even if they have recently met, there is an atmosphere of
mutual respect as they both want the project to succeed. Rave described that the machine should accept
money and return change, a characteristic that will make the software easier to use. They brainstormed
a lot. Tristan, having years of experience as a business analyst, continued to let Rave hear ideas,
alternatives, and solutions for his requirements. After two hours, they ended up with a big list and Rave
shook his head. He is just a poor fish vendor and cannot afford to pay all those requirements. So Tristan
reviewed the list again and suggested ways to adjust requirements and accelerate development through
reuse. In this way, Rave can save a lot of time and money! After one year, Tristan came back to the
marketplace and Rave received an automated fish selling system that met his functional needs and
expectations. They all lived happily ever after, the end.

Rights of Software Customers (The customer has the right to...)


1. expect Business Analysts to SPEAK your language
Customers shouldn't have to wade through technical jargon when talking with business analysts.
2. expect Business Analysts to LEARN about your business and objectives
Inviting business analysts and developers in your workplace will help them create a solution
that meets your needs.
3. expect Business Analysts to RECORD requirements in an appropriate form
Requirements analysis have requirements stored in some appropriate form/document. These
requirements documents should be written and organized that customers will easily understand.
4. RECEIVE EXPLANATIONS of requirements practices
Certain practices (eg. Diagrams, notations, deliverables) recommended by the business analyst
must be explained to the customer along with the information that goes into each deliverable.
5. CHANGE requirements
The customer has the right to make changes in the requirements as the business evolves. It is not
realistic for business analysts or developers to make you think all of your requirements up front or
expect those requirement to remain static throughout the development cycle.
6. expect an environment of MUTUAL RESPECT
Developers and customers should treat each other with respect as everyone is working towards a
mutual objective of a successful project.
7. HEAR IDEAS, ALTERNATIVES, AND SOLUTION for your requirements
Customers should inform business analysts about obsolete processes and could expect business
analysts to suggest improvements in the business processes.
8. DESCRIBE CHARACTERISTICS that will make make the product easy to use
Business analysts should ask customers about software characteristics (quality attributes) which
will make the software easier or pleasant to use.
9. hear about ways to ADJUST REQUIREMENTS to accelerate development through REUSE
Adjusting requirements when sensible reuse opportunities are available will save time and
money.
10. RECIEVE a system that meets your functional needs and quality expectations
This is the ultimate customer right. This can happen when customers clearly communicate all,
but not limited to, information, options, expectations, and constraints to the developers.

Responsibilities of a software customer (A customer must have the responsibility to...)


1. EDUCATE business analysts and developers about the business
To help the team understand the business and your objectives as a customer
2. DEDICATE time to provide and clarify requirements
Customers are busy people but they must be patient to clarify requirements to ensure the
success of the project.
3. be SPECIFIC when providing details about requirements
Clarifying the intent to each requirement enables business analysts to communicate it to the
development team accurately to ensure that the product meets your needs.
4. make TIMELY decisions when asked by business analysts
When asked to make a decision, make that decision promptly because the time spent waiting for
an answer can delay progress.
5. RESPECT a developer's assesssment of the cost and feasibility of the requirements
Some features may be expensive to implement depending on the developer. An action to take
place instantaneously is not feasible, but a timing requirement such as within 50 milliseconds
might be achievable.
6. SET REALISTIC requirements priorities
Marking every requirements as high priority is not realistic.
7. REVIEW requirements and EVALUATE prototypes
The feedback on reviewing requirements and evaluating prototypes provides valuable
information to the developers about what you want and do not want. This a a way to validate the
requirements.
8. establish ACCEPTANCE CRITERIA
The customer must define the characteristics of a requirement for it to be marked as done so
that developers and testers know when they are finished or not.
9. COMMUNICATE CHANGES to requirements EARLY
The later in the development a change is introduced, the greater its impact on the project.
10. RESPECT the requirements development process
Requirements elicitation and specification is the greatest challenge in software development.
Mutual understanding and respect for each other's approaches lead to an effective collaboration.

Requirements development process framework

Business Analyst Role


The business analyst is the individual who has the primary responsibility to elicit, analyze,
document, and validate the needs of the project stakeholders. The analyst serves as the principal
interpreter through which requirements flow between the customer community and the software
development team, as shown in Figure 4-1. Many other communication pathways also are used, so the
analyst isnt solely responsible for information exchange on the project. The BA plays a central role in
collecting and disseminating product information, whereas the project manager takes the lead in
communicating project information.
Business analyst is a project role, not necessarily a job title. Synonyms for business analyst
include requirements analyst, systems analyst, requirements engineer, requirements manager,
application analyst, business systems analyst, IT business analyst, and simply analyst. These job titles
are used inconsistently from organization to organization. One or more dedicated specialists could
perform the role on a given project or it could be assigned to team members who also perform other
project functions. These team members include project manager, product manager, product owner,
subject matter expert (SME), developer, and sometimes even user.

Tasks of a Business Analyst


1. Define business requirements
2. Plan the requirements approach
3. Identify project stakeholders and user classes
4. Elicit requirements
5. Analyze requirements
6. Document requirements
7. Communicate requirements
8. Lead requirements validation/verification
9. Facilitate requirements prioritization
10. Manage requirements
Essential Business Analyst Skills
1. Listening skills
2. Interviewing or questioning skills
3. Thinking on your feet (Quick and critical thinking skills)
4. Analytical skills
5. Systems thinking skills
6. Learning skills
7. Facilitation skills
8. Leadership skills
9. Observational skills
10. Communication skills
11. Organizational skills
12. Modeling skills
13. Interpersonal skills (Be able to work in teams with different individuals)
14. Creativity skills

Anda mungkin juga menyukai