Archive for the ‘Documentation’ Category
Tuesday, December 13th, 2011
Security requirements are a difficult quality attribute to elicit and specify. (Quality attributes are one the three types of nonfunctional requirements—along with interfaces, and design & implementation constraints*). Distinguishing can help. So too, it helps to
Sue Burk distinguishes between security requirements and security controls, shares four categories of security requirements, provides suggestions for eliciting security requirements, and explains why making them testable is important in her expert response. Continue reading
Tags: BABOK, Business Analyst, Business Value, Elicitation, Planguage, Quality attributes, requirements, Security Requirements
Posted in BABOK, Business Analysis, Documentation, Elicitation, iiba babok, requirements, Security Requirements, Sue Burk | No Comments »
Tuesday, June 21st, 2011
Are you working on data-centric software products? For example, ones that involves building a data warehouse, using extract-transform-load (ETL) and getting the gold—delivering business intelligence and analytic reports and queries for business decision makers?
Sue Burk shares the value of scenarios to define acceptance tests, and other practical techniques to improve your success with these data-centric projects in her expert response. Continue reading
Tags: Analytics, BABOK, Business Analyst, Business Intelligence, Data, Documentation, Elicitation, requirements, Scenarios
Posted in Analysis, Analytics, BABOK, Business Analysis, Business Intelligence, Data, Documentation, iiba babok, requirements, Scenarios, Sue Burk | No Comments »
Tuesday, June 7th, 2011
I was recently interviewed by SearchSoftwareQuality editor Yvette Francino about this week’s Business Analysis and Requirements Workshop at the Better Conference/Development Conference this week in Las Vegas, Nevada (6-7 June, 2011).
Yvette asked me to explain the logistics, if we would be emulating gathering requirements for a particular project and if the workshop be relevant regardless of domain area. Here are my answers: As conference chair, Continue reading | 1 Comment
Tags: Agile, Agile BA, Agile Business Analysis, Agile Business Analyst, agile requirements, BABOK, Business Analyst, business analysts role, Business Value, Documentation, Elicitation, Product Owner, requirements, Stakeholder Analysis, Stakeholders
Posted in Agile, Agile Business Analysis, Agile Business Analyst, agile requirements, Agile Workshops, Analysis, BABOK, Business Analysis, Business Analysis Training, Business Analyst, Business Value, collaboration, Communication Skills, Documentation, Elicitation, ellen gottesdiener, Facilitation, iiba babok, lean, Learning, requirements, retrospectives, Stakeholder Analysis, Stakeholders, Waste, Workshops | 1 Comment »
Thursday, April 7th, 2011
By Ellen Gottesdiener and Mary Gorman
In September 1977, the TV sitcom Happy Days had über-hip Fonzie, clad in leather jacket and swimshorts, water ski over a shark to prove his mettle—and at that moment even diehard fans knew that the show was past its prime. They were right. After that episode, ratings plummeted, and the expression “Jumping the Shark” was born. When a TV show, or anything else, jumps the shark, you know it’s on its way out.
Our question this month: have any of your software development practices jumped the shark?
For example, are there boundaries around people’s roles? Some organizations tend to confine people to roles such as developer, architect… Continue reading
Tags: Agile, agile team, Business Value, Documentation, leadership, product needs, Product Partnership, Product stakeholders, requirements, retrospectives, Stakeholders
Posted in Agile, Agile Business Analysis, Agile Business Analysis Flow, Agile Business Analyst, agile games, agile manifesto, Business Analysis, Business Value, collaboration, Communication Skills, Documentation, ellen gottesdiener, heavyweight team, leadership, lean, mary gorman, Product Partnership, requirements, retrospectives, roles and responsibilities, Stakeholders, Waste | No Comments »
Tuesday, March 15th, 2011
Have you been in a situation where there’s no documentation, yet you’re expected to understand functionality?
Trial transactions and observing behavior is one answer. But understanding context is also important.
Sue Burk suggests creative solutions in her expert response.
Tags: Business Analysis, Business Analyst, Documentation, Elicitation, product needs, Product requirements, Product stakeholders, requirements, Requirements Management, Software Requirements, Stakeholder Analysis
Posted in Agile, Agile Business Analysis, Business Analysis, collaboration, Discovery Workshop, Documentation, Elicitation, Elicitation Workshops, Facilitation, Process Modeling, requirements, Requirements Analysis, Stakeholder Analysis, Sue Burk, Workshops | No Comments »
Security requirements are a difficult quality attribute to elicit and specify. (Quality attributes are one the three types of nonfunctional requirements—along with interfaces, and design & implementation constraints*). Distinguishing can help. So too, it helps to
