Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Business Proces...  Requirments Analysis Main techniques:
Previous Previous
 
Next Next
New Post 4/13/2009 7:37 AM
User is offline Ahmad_Hammoud
5 posts
www.modernanalyst.com
10th Level Poster


Requirments Analysis Main techniques: 

 

Stakeholder identification
A major new emphasis was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:
  • those organizations that integrate (or should integrate) horizontally with the organization the analyst is designing the system for
  • any back office systems or organizations
  • Senior management.
Each use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective, a use case describes just one feature of the system. For most software projects, this means that perhaps tens or sometimes hundreds of use cases are needed to fully specify the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case.
A use case defines interactions between external actors and the system under consideration, to accomplish a business goal. Actors are parties outside the system that interact with the system; an actor can be a class of users, a role users can play, or another system.
Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is deliberate policy, because it simplifies the description of requirements and avoids the trap of making assumptions about how this functionality will be accomplished.
A use case should:
  • describe a business task to serve a business goal
  • be at an appropriate level of detail
  • be short enough to implement by one software developer in a single release
Use cases can be effective for establishing functional requirements for some but not all types of projects. Use cases focus on users' interactions with the system, and as such work well for end-user applications. However use-cases are much less valuable in projects where deep complexity does not lie in user interactions, such as: batch processing, data warehousing, or systems with complex computations or detailed calculations.
Use cases are not suited to capturing Non-Functional Requirements. However Performance Engineering specifies that each critical use case should have an associated performance oriented non-functional requirement.
Software requirements specification
Further information: Software requirements specification
A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).
Stakeholder interviews
Stakeholder interviews are a common method used in requirement analysis. Some selection is usually necessary, cost being one factor in deciding whom to interview. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.
Joint Requirements Development Sessions (a.k.a., Requirement Workshops)
Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator, wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A dedicated scribe and Business Analyst should be present to document the discussion. Utilizing the skills of a trained facilitator to guide the discussion frees the Business Analyst to focus on the requirements definition process
Contract-style requirement lists
One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages.
Measurable goals
Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.
Prototypes
Main article: Prototyping
In the mid-1980s, prototyping was seen as the solution to the requirements analysis problem. Prototypes are mock-ups of an application. Mock-ups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.
However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:
  • Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
  • Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
  • Prototypes principally help with design decisions and user interface design. However, they can't tell you what the requirements originally were.
  • Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
Prototypes can be flat diagrams (referred to as 'wireframes') or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the software design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.
Use cases
Main article: Use case
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.
Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner.
Main techniques:
 
Conceptually, requirements analysis includes three types of activity:
·         Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
·         Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
·         Recording requirements: Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops - see below) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  Requirments Analysis Main techniques:

Community Blog - Latest Posts

Jason White
Jason White
With time, we have evolved from oiled lamps to ever-present electricity, printing every page manually to now producing thousands of copies a day and so on. But what is the one thing these distinct things have in common? Yes, technology.One such branch of technology that has crossed leaps and bounds and turned into a  working technology fr...
0 Responses
Digital Business Analysis
Digital Business Analysis
Nowadays, companies like Audi and HSBC, use IT systems in everything they do. Does that make them to be IT companies rather than banks? Most would probably agree that HSBC is a bank, just as Audi is a car manufacturer. But what about digital banks such as Chime or companies offering digital products? In digital companies, most of the employees work...
0 Responses
Digvijaybook
Digvijaybook
IT companies are rapidly looking or adapting modern methodologies, so the business analyst role is increasing day by day. Offline is shifting to online, and this is why today, companies can easily garner important data in any aspect. But, data itself has no meaning hence, organizations look for a business analyst who can analyze the data and draw a...
1 Responses






Latest Articles

Knowledge First, IT Last
Jan 26, 2020
0 Comments
  Step one is get knowledge, step two: redesign for effectiveness then, lastly, step three, pull in IT. It is to start from a base of knowing wh...
Copyright 2006-2020 by Modern Analyst Media LLC