3630 Views
0 Likes
0 Comments

Study after study has shown poor requirements management is the leading cause of failure for traditional software development teams. When it comes to requirements, agile software developers typically focus on functional ones that describe something of value to end users—a screen, report, feature, or business rule. Most often these functional requirements are captured in the form of user stories, although use cases or usage scenarios are also common, and more advanced teams will iteratively capture the details as customer acceptance tests. Over the years, agilists have developed many strategies for dealing with functional requirements effectively, likely one of the factors leading to the higher success rates enjoyed by agile teams. Disciplined agile teams go even further, realizing that there is far more to requirements than just this, that we also need to consider nonfunctional requirements and constraints.

Nonfunctional requirements (NFRs), also known as "technical requirements" or "quality of service" (QoS) requirements, focus on aspects that typically cross-cut functional requirements. Common NFRs include accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness.

A constraint defines a restriction on your solution, such as being required to store all corporate data in DB2 per your enterprise architecture, or only being allowed to use open source software (OSS), which conforms to a certain level of OSS license. Constraints can often impact your technical choices by restricting specific aspects of your architecture, defining suggested opportunities for reuse, and even architectural customization points. Although many developers will bridle at this, the reality is that constraints often make things much easier for your team because some technical decisions have already been made for you. I like to think of it like this—agilists will have the courage to make tomorrow's decisions tomorrow, disciplined agilists have the humility to respect yesterday's decisions as well.

Although agile teams have pretty much figured out how to effectively address functional requirements, most are still struggling with NFRs and constraints.

Author: Scott Ambler

14623 Views
5 Likes
5 Comments

Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?

Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.

Author: Jan Kusiak

11386 Views
2 Likes
3 Comments

Many of us are familiar with the process of business analysis – start by gathering requirements from stakeholders then turn them into a specification which developers can understand. These days however, we need to do more than just document the requirements.

We need to work with stakeholders and business users to understand their systems and analyse their problems – why do you do it this way, why not that way? This is the real value add that the analyst brings to the table. It means challenging the status quo, pushing the boundaries, looking for alternative or creative solutions.

To develop a solution - unless we’re very lucky - we first need to understand the problem that drives the need. In this paper we'll look at how to understand and define business problems – part 2 will look at how to generate solution ideas and part 3 will cover how to choose the best ones.

Author: Jan Kusiak

20294 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.

22797 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.

13672 Views
7 Likes
1 Comments

Every career has a set of skills that one needs to do their job, and a set of tools to carry out the various tasks required to display their skills. Same is the case for the analyst involved in security assessment... I have chosen the all mighty checklist as my tool of choice for this article.

22338 Views
11 Likes
1 Comments

Every area of practice in IT has a set of specific “tools” that supports the standard work of technology professionals. Data Analysis is the capture of data requirements, development of models that reflect those requirements and creation of design to store the data. You can accomplish this with a pencil, paper, and the right skill-set. But it can be done much more quickly and consistently if the process is automated.

There are hundreds of individual software tools and tool-suites that support different facets of data analysis.

56609 Views
23 Likes
18 Comments

Whether you’ve never heard of Agile or you just finished your nth Agile project, you need to understand that Agile is here to stay! Are you, the Business Analyst, an extinct species in this new world? Is your career changing? Do you need new skills?

Agile guru and visionary Scott Ambler talked with Adrian Marchis, ModernAnalyst.com's Publishing Editor, and shared his vision on what’s next for Agile and his thoughts on the role of the business analyst in the Agile world.

16762 Views
3 Likes
1 Comments

Change seems to be a popular word in this pivotal election year. When I think about change, I recognize that it impacts each of us in many forms. One of the biggest changes I’ve experienced as a Business Analyst was the transition from working requirements in a traditional project lifecycle to an Agile methodology. The change was introduced to my project team as a management directive with management support.

Our project was an enterprise initiative funded as a multi-year program. The program was comprised of three parallel workstreams with shared releases. Our workstream’s objective was to build out data and data services for the other workstreams and the enterprise to use. The team was made up of experienced Information Technology (IT) professionals and a brand new business unit. We were halfway through the program’s duration when our workstream was called upon to employ Agile methods. The other two workstreams we serviced stayed with traditional waterfall software development, which presented challenges interfacing with each other. The entire program had already completed a Business Architecture phase that outlined the program’s objectives, future state vision, and capability implementation plan.

14144 Views
3 Likes
1 Comments

As an analyst practitioner I took it upon myself to act as a proxy for the product owner – which in a corporate environment came with the challenges of multiple stakeholders, the fact that you are not the product owner and thus don't really have the final say, and a number of other challenges that typically stump people trying to move to agile.

My circumstances were unique in some ways. I had worked in the organisation for some time and had established good relationships with all the key stakeholders. They really did trust me with their requirements because, over time, I had learnt (and shown I had earned) their business.

I also maintained high bandwidth communications with the stakeholders throughout the project and kept them informed of what was happening and how the system was shaping up in the context of their business needs. And expectations were managed.

16754 Views
9 Likes
1 Comments

As business professionals, we need to understand that security is everyone’s responsibility; and that is especially true for business analysts, project managers, systems analysts, and others in the position of defining processes, technical architecture, or decision support.

If you are involved in a project that deals with information business assets, then you need to be thinking about the confidentiality and integrity of those assets throughout your project.

There are questions you need to be asking yourself, as well as others on the project, to better understand the security implications of a particular process, technology, or design element of that project.

10315 Views
1 Likes
0 Comments

The ultimate management sin is to waste people’s time, Tom DeMarco and Timothy Lister told us in their famous book Peopleware [1]. This includes having pointless meetings that prevent people from actually doing anything useful. Nevertheless, some meetings are considered a necessary evil and therefore the so-called “agile movement” in software development has come up with an efficient way of dealing with this: the Stand-up Meeting in 15 Minutes. For those who have just woken up from ten years of hibernation, or having emerged from a cave that had no Internet access, I will explain this briefly.

A stand-up meeting is a daily meeting where people remain standing up to keep the duration of the meeting under 15 minutes. Teams use these meetings to answer three simple questions..

24426 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.

15751 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

149171 Views
100 Likes
12 Comments

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.

Page 64 of 77First   Previous   59  60  61  62  63  [64]  65  66  67  68  Next   Last   

 



 




Copyright 2006-2022 by Modern Analyst Media LLC