The problems most companies have with software development are due to poor requirements rather than coding. Developers know how to code but the business requirements are most often incomplete and don’t effectively communicate the business needs. The lack of effective requirements gathering and writing leads to 82% of the software re-design and maintenance efforts causing companies to waste millions of dollars a year on ineffective software implementations and lost product to market opportunities (based on a study done by James Martin).
Surveys of Pierson Requirements Group’s customers have found that using Pierson’s training and implementing collaborative requirements techniques has lead them to a savings of 25 – 40% of time and cost over the entire project or 3 to 4 months out of a year long project. Pierson Requirements Group provides both on-site and virtual instructor led training classes. The next scheduled Requirements Gathering & Writing is September 22 – 24 and October 4 – 6. For more information, contact jmatthews@piersonrequirementsgroup.com or click on the link http://www.piersonrequirementsgroup.com/contact.php.
http://www.prlog.org/10863376-pierson-requirements-group-announces-virtual-business-requirements-gathering-writing-class.html
Business requirements gathering and writing works best when the business analyst doesn’t throw the requirements over the cubicle wall to IT! Using collaborative requirements gathering sessions for scoping, high level requirements and detailed requirements should be conducted. If you involve the technical team in the detailed requirements sessions, you will have less churn and less chaos. Below is a description of the focus group sessions the Business Analyst can conduct:
- The first step would be to review the requirements use cases from the requirements sessions previously conducted.
- Once you have reviewed the high level requirements, you are ready to identify how the system will work with the SMEs, and Technical Leads. Using the requirements use cases, develop the detailed steps of the flows on the use cases. Using a ping-pong method, identify what the user will do and what the system response should be and document. The Business Analyst can use an Activity Diagram with swimlanes technique to help identify the detailed steps in the use case.
- While you are identifying the detailed steps, you can also note where you have screens and reference them on the use case. The Business Analyst should lead the Subject Matter Experts (SMEs) and the Technical Team in a brainstorming session using the storyboarding technique to collaboratively build screen mock-ups.
- The Business Analyst should then further define the screen specifications by capturing the details of the data fields on the screens with the team.
A good article that supports the importance of collaborative detailed requirements sessions as described above is as follows: http://advice.cio.com/jim_vaughan/10442/project_managers_need_to_engage_it_at_the_right_time
Pierson has trained and mentored the U.S. Census Bureau Re-design division on their templates, requirements process tools and methods. Pierson has trained all the project teams including the Project Managers, Subject Matter Experts, Business Analysts, Technical Managers, Programmers and Branch Chiefs in the new Re-design requirements gathering and writing process.
Click on the course name to view the course content. Business Requirements Gathering & Writing using JAD, Use Cases and UML.
For more information please contact wpierson@piersonrequirementsgroup.com or call 203-322-1606. Check out the website for www.piersonrequirementsgroup.com.
Add new tag, Business Analysis, business analysis training, Business Analyst, business analysts training courses, Business Requirements, System Analyst
Iterative Development is a process that speeds the delivery of functionality to end-users by segmenting a system into pieces for delivery, rather than delivering all of the system functionality in one large implementation. The iterative process utilizes a spiral methodology and is also customer driven following an evolutionary process using continuous application engineering in a timeboxed fashion with a dedicated professional team. The goal of the iterative approach is to reduce the time between requests and delivery of Business Application Systems. Some of the primary characteristics of iterative development projects are:
· There is a strict deadline for basic functionality
· Can be released in increments
· Uses techniques such as time-boxing, dedicated teams and focus sessions
· Business users are involved throughout the project and JAD is used
· Total project time is usually 3 – 6 months
Roles
The execution of an Application Project can involve a number of different actors, each with a specific role and set of responsibilities. The following table defines all the different roles and responsibilities that can be found on an Application Development Project. These roles always exist although the size and characteristics of the project may cause the same person to carry out more than one role.
Add and remove roles as appropriate. Make sure the responsibilities of each role are clearly understood. It is as important to list client responsibilities to ensure client resources have the appropriate authority.
|
Role
|
Responsibilities
|
|
Roles
|
|
|
|
|
|
Project Manager
|
Produce Project Definition Document.
Manage project schedule.
Manage project budget.
Manage change, issues risk and status.
|
|
Technical Manager
|
Schedule and manage day-to-day development activities.
Resolve technical issues.
|
|
Test/QA Manager
|
Define system test plan & test cases.
Execute system test plan.
Schedule testing resources.
Ensure application adheres to standards.
|
|
Business Analyst
|
Analyze and document client requirements.
|
|
Developer
|
Produce Prototype (optional).
Produce Design Document.
Code the application.
Unit test code.
Fix bugs in a timely manner.
|
|
Tester
|
Test the application to ensure it complies with the Requirements & Design Documents.
|
|
|
|
|
<Client> Roles
|
|
|
Sponsor/Champion
|
Sign-off on major deliverables and budget.
Participate in phase-end reviews.
Assign client resources to the project.
Eliminate roadblocks and motivate staff.
|
|
Client Project Manager
|
Primary point of contact for Hallmark.
Sign-off on major deliverables.
Approve change requests & change budget.
Participate in phase-end reviews.
Coordinate client meetings, participation in workshops, training and status meetings.
|
|
Other Client Representatives
|
Participate in analysis & design workshops.
Ensure the requirements specification meets the needs of the organization.
Participate in User Acceptance Testing.
|
|
|
|
|
TBD Roles
|
|
|
Rollout manager
|
Plan and manage installation activities.
Plan/coordinate conversion activities.
|
|
Support manager
|
Provide ongoing product support.
|
|
Training manager
|
Develop training plan (with client lead).
Develop training material.
Train employees on the system.
|
|
Documentation manager
|
Develop user documentation & help.
|
The purpose of an iterative development approach is to separate a development project into logical and manageable units for incremental delivery. The completion of each iteration adds to the knowledge about the system being developed and reduces the risk when progressing to the next iteration. It also provides a repeatable method for business system development. It provides business user sign off and approval before continuing to commit resources to the project.
Reusability is also described throughout the system development process. Reusing previously developed parts in a product is a significant way of decreasing the product’s life cycle cost. Reuse in software engineering means deliverables that can be reused later. This includes all the information and knowledge that has been developed, such as; system architectures, development methods, program code and completed algorithms.
List of interview questions to define the user requirements for the new EDW
What data will go in the warehouse?
How will they use that data?
What Type of Data is needed?:
What information is important to access?
Sources of Data: What data is needed from excel format, etc.
What type of reporting is needed?
What is the method of accessibility?
Technical Questions:
What questions/problems you would like to be answered by mining in EDW?
How many years of information would you like to store?
How often the data should be refreshed in the EDW? How often to load data, weekly, monthly?
What kind of reports you would like to see? What kind of information is needed? i.e. HR data- turnover from start date to end date.
What format you would like to see your reports? Pie chart, bar chart, etc.
