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
To Succeed in An Environment of Growth and Excellence and Earn A Job Which Provides Me Job Satisfaction and Self-Development and Help Me Achieve Personal As Well As Organization Goals