We have some potential resources for you at our site, http://www.b2ttraining.com/downloads/ . Select the Requirements Validation Template download. There are a number of templates for creating test cases, plans, etc.

Let me know if this helps. Thanks,

Kupe

You are right on when it comes functional vs technical and technical for a BA is functional for a developer. Last week I had this conversation with a developer on a data integration project I am on.

Check out this discussion on LinkedIn that dipped into this topic. http://tinyurl.com/m6s49l

I agree with Jinesh: “Depending on the willingness, skills, experience, SME,etc…a BA can choose to be more on the technical side or sway more on the business side during his/her project lifecycle”.

In my company tthis question depends on the roles defined for a project.

In the past, we used to have a business analyst (BA), a solution analyst (SA) and a development team working on each project. The BA was doing the enterprise analysis, writting the business requirements, the business rules and user requirements as use cases. This was the input for the solution analyst who has the functionnal expertize and writtes the functionnal and non-functionnal requirements. Then the development team take over and writte the design requirements as well as technical seq diagrams… as they know best the implementation.

Now my company has decided to merge the roles BA and SA. Both roles will train each other on their expertize. In the end the BA will be writting BRs as well as functionnal requirements.

May be we can spend sometime to define what does technical means because what is technical for a BA is often functionnal for a developper.

Although the perception of a BA role is to bridge the GAP, but I believe BAs do /should have a boundary in their role. My mantra is let the “Experts” take care of their jobs.

Depending on the willingness, skills, experience, SME,etc…a BA can choose to be more on the technical side or sway more on the business side during his/her project lifecycle. In my experience, BAs traditionally ,over their entire career, seek to move away from Technology and more towards Business.

As Declan mentioned, BAs should be involved in Design phase. Bas can validate the Tech Specs against Requirements.

Also agree with Andreas, that it is the Software Architect’s role to find a solution. But BAs can add value to their role by being “solution enablers”.

I am always excited to learn more about the Business, their To-Be state, strategy,etc… but at the same time High Level Architecture diagrams, Logical Data Designs(ERD) interest me as well. But any thing more detailed than these documents are a strict no-no for me personally, since I am not the expert.

Most customizations are written from the user’s viewpoint. i.e. Which screens are modified is the primary driver. This format is easiest for communicating with the client and is a good way to separate “what” needs to happen from “how”. The developers then write a Technical Design Document based on my requirements.

In some cases we are modifying tables in the database or are providing new back-end functionality. These documents are typically more technical.

For “technical requirements” I read “system requirements”. For “technical design” I read “system design”. To me, the former means: “What I need the system to do” whereas the latter means: “How the system will go about achieving what you need it to do”.

As an analyst, I do not document the latter at all, since it belongs to the solution domain. Moreover, I try to word the requirements as clearly and concisely as possible while allowing the designers maximum latitude.

However, I agree that the BA should be involved in the design sessions on a consultative basis, as long as the BA can understand the design concepts being discussed.

In recent years I have worked a lot with Pegasystems’ PRPC, an excellent BPM / Rules Engine tool. I have been involved with this tool as a developer, team manager and business analyst. Although my involvement has mostly been as an analyst my development experience gives me insight which another analyst might not have.

As a result, when analysing system requirements I am able to advise the customer as to the kind of features the tool can give them “out of the box”, so that they don’t spend time and money re-inventing the wheel. I also like to have someone with more PRPC design experience in the analysis sessions who can help me give such advice.

However, where an “out of the box” component does not exist to satisfy the business need, the language of the requirements refers to the problem domain only and not the solution domain.

Kind regards,

Declan