Requirements Analysis (BABOK KA)

22489 Views
8 Likes
1 Comments

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

25182 Views
7 Likes
0 Comments

While working on a Business Architecture effort several years ago, I collaborated on developing a new internal standard for business process and business capability description. From my perspective, a business capability is the required function or desired service that a business unit performs and the business process is the set of methods employed to realize the business capability. Business capabilities and business processes can be described as current or future state. Their description can also be scaled for strategic or tactical objectives.

This article will present an approach for documenting and aligning business capabilities, business processes, and functional requirements by integrating two distinct tools that leverage robust repositories and object metadata.

27490 Views
12 Likes
0 Comments

Software production has become one of the key activities of the industrialized world. Software applications are now the driving force of business, government operations, military equipment, and most of the services that we take for granted: electric power, water supplies, telephones, and transportation.

Most major companies and government agencies build or commission new software applications every year. But software development and software contracts have been very troublesome. Cost and schedule overruns are common, and litigation for software problems is a frequent outcome. Successful development of large software projects is so difficult that significant percentage of large systems greater than 10,000 function points are canceled and never completed.

One of the major challenges of software cost and schedule estimation is “sizing” or predicting the amount of source code and other deliverables that must be built to satisfy the requirements of a software application. Sizing is a critical precursor to software cost estimating whether estimation is done manually or by means of a commercial software cost estimating tool.

For software applications that are similar to existing applications, size can be derived by analogy to the existing packages. When the software application is a new kind of application then sizing by analogy is not a feasible approach.

For much of the history of the software industry, sizing was considered a very difficult and intractable problem. Sizing is still difficult, but over the past 30 years an interesting new methodology for dealing with size prediction has been developed based on the use of the function point metric. This new methodology has the advantage that it can not only predict the volume of source code, but also the volumes of planning documents, specifications, user manuals, test cases, and even the probable number of errors or bugs that might be encountered.

 

 

 

Author: Capers Jones is the President of Capers Jones & Associates LLC. He is also the founder and former chairman of Software Productivity Research, LLC (SPR), where he holds the title of Chief Scientist Emeritus. He is a well-known author and international public speaker, and has authored the books “Patterns of Software Systems Failure and Success,” “Applied Software Measurement,” “Software Quality: Analysis and Guidelines for Success,” “Software Cost Estimation,” and “Software Assessments, Benchmarks, and Best Practices.” Jones and his colleagues from SPR have collected historical data from more than 600 corporations and more than 30 government organizations. This historical data is a key resource for judging the effectiveness of software process improvement methods. The total volume of projects studied now exceeds 12,000. 

Copyright * 2008 by Capers Jones & Associates LLC.  All Rights Reserved.

17653 Views
3 Likes
0 Comments

The Volere requirements techniques were developed to answer the need for a common language for discovering requirements and connecting them to solutions. The language needs to be understandable by business people, customers, business analysts, engineers, designers, suppliers, testers or anyone else whose input is needed. All of these people have different skills and, not surprisingly, different views of what is important. A language intended for all of these people must recognise the differences in peoples’ viewpoints and yet have a consistent way of communicating and tracing the
relevant knowledge. This realisation that requirements is a socio-technical discipline has a strong influence on the development of the techniques.

Author: Suzanne Robertson & James Robertson, The Atlantic Systems Guild

22885 Views
2 Likes
0 Comments

"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."

In this article Ellen covers a number of agile requirements topics including:

  • Agile requirements need to be understood in context of the product, release, and iteration
  • Balancing Business and Technical Value
  • The Product Workshop
  • Release Workshops
  • Iteration Workshops
16678 Views
4 Likes
1 Comments

“The biggest risk to your company is not being able to change fast enough… Business Rules are the answer.” …Ron Ross

I am a great appreciator of Mr. Ross. He has written extensively on the topic of Business Rules, offers excellent training on the subject, and is the keynote speaker at each year’s International Business Rules Forum. I would like to start my own article on Business Rules with an ‘icebreaker’ he used on a seminar I attended.

Consider the sport of American Football. Some aspects of the game are very stable, some less so, and some not necessarily stable at all.

Author: David Wright

188194 Views
68 Likes
7 Comments

As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems (www.sparxsystems.com) for a number of years. In that time I’ve spent considerable time and energy trying to get our business analysts to do the same. While I’ve had some success I must admit it’s been an uphill battle. I suspect this is partly because EA is often seen as a technical person’s tool. And that’s not altogether surprising.

  • Enterprise Architect – the name itself is completely misleading. EA is not only for people with the title ‘Enterprise Architect’. It’s for the entire project team, from BA’s to Testers and even for Clients.
  • User Interface – for developers the user interface of EA is extremely familiar and intuitive. It looks like a lot of the tools they use already. For non-technical users more familiar with tools like Microsoft Office it is somewhat more intimidating.

So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.

15710 Views
1 Likes
0 Comments

The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.

In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices

20035 Views
8 Likes
8 Comments

A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time.

After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no.

Let’s see this concept in practice in the “Requirements for My New Car”: a fable.

6668 Views
0 Likes
0 Comments
Defining business requirements accurately is one of the most important success factors for technology projects.  Rather than focus on solutions that satisfy a list of requirements, we need to focus on solutions that satisfy desired business outcomes. The best way to achieve this is by performing business process modeling.  Employing a vi...
8789 Views
1 Likes
1 Comments
To be honest, I'm not very enamored with the term "best practice". I believe that the term "contextual practice" makes far more sense because what is a "best practice" in some situations proves to be a "worst practice" in others. Having said that, people are interested in best practices so here they are when it comes to agile requirements modeling:...
10235 Views
4 Likes
0 Comments
Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the r...
9116 Views
1 Likes
0 Comments
There are three basic reasons why you might need to model a business: to re-engineer a business, to improve a business process and to automate a business process. Nevertheless, another reason may be very useful for analyst of software systems and their customers – to understand and automatically generate functional requirements to the system. ...
11864 Views
2 Likes
1 Comments

Have you noticed the examples of requirements elicitation on my blog? In one case, I had a bit of a contest, using a game to elicit information. You can see this technique by looking in the category Online Game on the blog. Then I had a survey to elicit information. You can see that survey by looking in the category Survey on the blog. Today I am going to use the information from the survey to show you another technique you might use when developing requirements. That technique is writing Personas (or Personae for you Latin fans).

You write a Persona when you want to understand your customers better. This Persona is a story you will tell about a typical (but not real) customer. The Persona is a composite story about your typical customers, made very lifelike.

4360 Views
0 Likes
0 Comments
Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increas...
Page 10 of 13First   Previous   4  5  6  7  8  9  [10]  11  12  13  Next   Last   

 



 




Copyright 2006-2023 by Modern Analyst Media LLC