Requirements Analyzer

www.visiblethread.com/wp-content/uploads/VisibleThread-Vetting-documents-for-quality-The-case-for-automation.pdf

2011-07-04T21:16:00.000-07:00

www.visiblethread.com/wp-content/uploads/VisibleThread-Vetting-documents-for-quality-The-case-for-automation.pdf

a very interesting read to go along with stylewriter, SAT, and requirement analyser (DOORS) for conducting textual analysis of requirements

2010-06-18T01:30:00.001-07:00

In Requirements Analysis the systems engineerer, software engineeer or business analyst must evaluate the interviews, surveys, data, information, diagrams, tables, and screenshots provided to them.

What objective methods should be used to analyse this information defined as requirements? There are the standard requirement quality attributes such as completeness, unambiguous, testable, correct, necessary to test for.

What other information is important?

What tools are available to test the attributes?

How can we verify that a set of requirements meet the requirement quality attributes?

BA tools

2010-06-17T23:30:00.000-07:00

As BAs we need tools that support the elicitation, evaluation and management of requirements. I want to give a list of requirement related tools and ask your opinon of them

1) blueprint requirements center http://www.blueprintsys.com/

2) RavenFlow http://www.ravenflow.com/

3) Cameorequirements+ http://www.cameosuite.com/products/requirements/cameoreq

4) iRise http://www.irise.com/

5) TechExcel http://www.techexcel.com/

6) Axosoft http://www.axosoft.com/

7) BrightGreen Projects http://www.brightgreenprojects.com/

8) TopTeam http://www.technosolutions.com/topteam_requirements_management.html

I am a systems engineering in a BA world and I want to know what you think if any of these tools would help in the BA world. I don't know if the BA world uses things like requirements modeling, use case modelling, requirements management tools, and requirements visualisation tools and I would like to know if the community would use these types of tools or is a document and a spreadsheet sufficent.

Requirements analytics

2009-10-21T21:12:00.000-07:00

What the heck is requirements analytics? Well, analytics is the science of analysis. Requirements as we all know is the needs, wants and desires of a group of stakeholders to meet specific goals for a business or system. Requirements analytics is the science of analyzing requirements. I have only found the term used in one article "r-AnalytiCA: Requirements Analytics for Certification & Accreditation " http://www.computer.org/portal/web/csdl/doi/10.1109/RE.2007.34. Although it is an academic paper I think it is very relevant in the analysis of requirements. There needs to be a distinction between requirements analysis which has multiple meanings:

1) the process of elicitation, elaboration, documentation and review of requirements

2) The analysis of information to identify requirements

3) The analysis of legacy and derived requirements in whatever format the requirement is provided

Requirements analytics would be the use quantitative and qualitative techniques to analyse, model, measure and manage requirements to identify issues and risks that provides relevant information to key decision makers on the quality of requirements prior to development and testing. Requirements analytics would include areas of research into natural language processing, statistical modelling, game theory, decision theory, requirements visualization, risk analysis, cost benefit analysis, cognitive distribution, socio-technical modelling, ontology, taxonomy, concept graphing, goal-oriented modelling and analysis.

I will write more as I think of it.

What do you think?

How mature are your requirements?

2009-10-21T21:06:00.000-07:00

I found a great article on maturity of requirements I think you would enjoy

http://www.batimes.com/component/content/article/106-articles/517-business-analysis-benchmark-the-path-to-success.html

some of the findings I thought was interesting in the article was that a company that does have a good Requirements engineering process

Average on-time performance of technology projects increased by 161%.
Time overruns on projects reduced by 87%.
Average on-budget performance for technology projects improved by just over 95%.
Budget overruns reduced by just under 75%.
Percentage of projects that deliver the functionality needed by the business rose by just over 75%.
Average functionality missed dropped by approximately 78%.

What this means is using techniques such as modelling, textual analysis, prototyping, traceability matrix, and Verification Cross reference matrix improve the overall success of your project. What do you think

Requirements Elicitation and People

2009-07-09T22:07:00.000-07:00

As a systems engineer trying to explain what makes us different than say an Electrical Engineer or Software Engineer is difficult even to other systems engineers. The difference is people. Systems Engineers don't just look at the requirements, design, integration, verification and validation (RDIVV) of a system, but also must include the system. As I have stated in other postings systems developed by people are for people; therefore the most important portion of any elicitation process is the people. People include individuals, groups, departments, organizations, and businesses. Think about that for a moment before going on.

A a person you must define a system be it a text editor or a CRM suite why do we create requirements. I honestly believe it is for people; therefore what should we focus on people!!!! For the last ten years I was always taught that learning to imagine the system functions is the most important (from a systems engineer perspective), but I thought and found that what IS important is what people want.

New to the domain of Business Analyst, but having the same spirit, I believe strongly that what is important that anyone who developes, elaborates, and evaluates requiremensts is people skills. People skills include negotiation, mediation, facilitation, communication, besides eliciation. I will expand on these concepts in other posts. I want to send you to a good blog post I found that you might find interesting on how to handle pushback. I hope you get out of it as much as I did.

Getting good requirements

2009-07-06T16:55:00.000-07:00

When you ask your customers which requirements are the most important, do you get the answer they all are. How do you identify really what are the important requirements and what are the less important requirements. Well, I ran across a really good site you might appreciate for eliciting and prioritising requirements Innovation Games. It is a collaboration website that supports Serious Gaming and Serious Play. In particular they have a really cool game called Buy a Feature that I think is just perfect to get customers to identify the most important features/requirements of a system.

Live Scribe got to get me one

2009-06-18T00:18:00.000-07:00

This a tool I would love to use while developing requirements and I suggest whole heatedly you purchase. The ability to record the audio and text at the same time just proves that not everything can be evaluated through written text or diagrams. Take a look for yourself Live Scribe

Business Analyst or Requirements Engineer

2009-06-18T00:10:00.001-07:00

Requirements are requirements. Who cares who finds them or writes them. I come from a background of engineering, but I currently live in a world of accountants, financial analysts, customer representatives, managers, and executives. Looking through the literature in Australia between Electrical Engineering through IEEE Computer Engineering through ACS, Industrial Engineering through IEA, the encompassing Engineers Australia and Business Analysts through IIBA and ABAA we all desire to achive a set of information that represents a system. What I don't understand is why each of these groups develop a single group that works together to develop a framework that can develop any system.

What I want to know is why is it all these organizations (all the others I have not mentioned) cannot come together to come up with a system to elicite, elaborate, evaluate, verify and valiate requirements. I don't know the answer, but I will find out. if anyone can contribute to this idea please comment

Modeling Requirements

2009-06-17T23:11:00.000-07:00

This is going to be short. I want to talk about a few tools I have found that are great for modeling information, knowledge and requirements. I have used these tools for requirements elicitation, modeling and project management. I hope you will give them a go.

I have found a really good software application I think everyone should know about called Flying Logic. It is a diagramming application, but what I like about it is the simplicity of use. It auto arranges nodes, creates interconnect nodes on the fly. It is just such an easy tool to get up and running to make your self more productive. Flying Logic is about ~$150.00 USD.

In addition, you can add information to each node to clarify information. Another tool I would never give up is Mindmanager from Mindjet. This has got to be one of the best applications ever for Windows. If you have information that you want to manage and would like to export it to Microsoft office products this is the tool. Mindmanger has very powerful mind mapping functionality that can link tasks into Microsoft Outlook and Microsoft Project. If you are like me that thinks in pictures and not always in a logical form this is a tool for you especially for requirements elicitation where follow ups and time management are so important. Mindmanager costs about $500.oo USD.

Another mind mapping tool is Freemind the functionality is not a complete as Mindmanager, but it is free you should have a go.

Another mind mapping tool I have run across over the last month is xMind. This is a great mind mapping tool very powerful for brainstorming and mindmapping still not as capable as Mindmanager, but for free for most of us and $50.00 USD for the pro version a year it would take 10 years to reach the cost of Mindmanager and it is open source as apart of the eclipse project.

Requirement Elicitation Tools Part 1

2009-05-04T23:14:00.001-07:00

Requirements Elicitation techniques have used tools such as window layouts,
paper based user experience, audio interviews, interview forms, workshop meeting minutes, whiteboard pictures, video interviews, apprenticing videos, apprenticing journals, documents and spreadsheets to record information during the Requirements Elicitation process. Lets go through some of the values of each of these techniques.

Documents
Documents come in several forms word documents (most common), text and pdf. Documents are a simple well understood format for all parties (Business Analyst, Systems Analyst, Business, Systems Engineer, Software Engineer, Engineer, Tester) to understand. Documents present information in different ways such as text, diagrams, pictures, and tables in an organized manner. Documents are easy to use by just recording information in a format that the Business culture is use to (status que). Ther are simple method to pass around to SMEs and other important individuals in the requirements elicitation process. They can be emailed to the respective parties for review. If the project is using MS Word tracked changes are used to review the requirements. The tracked changes identify issues with the requirement set, format of the document, grammatical errors and spelling errors for the document.

Documents can be linked to a Wiki a website or other tools (explained in Part 2). The most common format is in Microsoft Word for internal use or with customers that trust the Business Analyst or requirements engineering team. pdfs are used when and outside source is used or trust is an issue between the business and developers.

Spreadsheets
Spreadsheets or CSV files are used in most traditional requirements gathering methods. They provide a simple method to record requirements and the associated attributes such as priority, complexity, associated function, responsible project, traceability to parent requirements, traceability to child requirements, comments, issues and associated component.

Workshop Meeting Minutes
Workshop meeting minutes can be a great source of information. They contain all sorts of information related to the requirements in a chronological form. I would recommend that if you use workshop meeting minutes that you provide enough time for the analyst to review the meeting minutes and develop follow on questions to the relevant subject matter experts

Whiteboards
Whiteboard pictures are such a great and easy way to acquire information from a large group. some techniques I would suggest in using whiteboards is brainstorming, activity diagrams, and mindmapping. In addition, always bring a digital camera to take a picture of the whiteboard prior to erasing the information. As a minimum use the camera on your mobile phone.

Interview Forms
Interview Forms create a structured method to conduct requirements elicitation. They are great for having consistent interviewing tehniques and making sure the analyst does not miss the core information for a specification. I will talk about what should and should not be in an Interview form on a later posting

Audio Interviews
Audio Interviews are used to record all dialogue between the interviewer and interviewee. The audio transcript is used to identify additional information to identify and record requirements

Video Interviews
Video Interview are a great tools that automatically records interviews. Information that a analyst may not pick up or forget is logged to the video. In addition, if the analsyst is trained in body language techniques (another item to talk about in another post.

Apprenticing Videos
I have used apprenticing videos several times on various projects not just for requirements such as on the job training manuals. These videos are extremly valuable for reviewing techniques that are described and noted in your apprenticing journal. They can provide additional information when reviewing requirements and present supporting rationale for a use cases and sets of requirements in the user's own words and actions.

Apprenticing Journals
I constantly use apprenticing journals. I will devote a whole paper on journals, how to write them how to use them in elicitation and when not to use them in specification writing. The apprencticing journal is not only about walking around observing users in their task but also noting things out of the ordinary unusal situations identified and questions asked and answered.

Window Layouts
Window Layouts are used to diagrammatically represent the user's desired layout of controls, text, pictures, and control flow. Window Layouts show to a customer or end user what information is presented by the system and the control flow of the presentation. They are used to Elicit errors in the requirements and layout of information during the Requirements Elicitation process

Paper Based User Experience
Over the last few years the industry has identified a need to create tools to capture this knowledge and are in vogue now.