5

I am struggling in my brain about what the right answer is here and where the gap in our requirements gathering process is on this team.

  • Non-technical BA - their role is to write Business and User requirements in the form of User Stories. When there is a compelling business reason for defining a general system behavior though they will write user stories with a system actor. They define Acceptance Criteria for these stories.

  • Business Systems Analysts and SE's - our role is to take Business and User requirements and derive Functional Requirements from these. We will generally define system actors and define system behavior with traceability back to business requirements and user stories.

The gap I am confused about is that the Business Requirements and User stories generally don't define the necessary details needed to describe functional components and I am not sure they even should. The Non-Technical BA's wouldn't understand the intricacies of how to do this even if we asked them to so it seems they belong in the Functional Requirements, however according to the formal definition of functional requirements they are to define the behavior of systems:

A function is described as a set of inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Functional Requirements (Wikipedia)

Everybody on the team is dealing with this differently right now. Our approved document for capturing FR's is limited in a way that forces us to define functions of a component and not details of the component itself. Some BSA's and SE's are defining functions with empty conditions and acceptance criteria and using the Inputs field to define properties of the component. Others still are not even capturing the information or they have it scattered in notes that they attach to functions.

Others still argue with the Non-Technical BA's claiming their requirements aren't specific enough and the Scrum master's answer is encouraging us to split things into total obfuscated oblivion with the hope that things become more estimable.

Is my understanding of the definition of functional requirements limited here?

CLARIFICATION: I felt I should clarify that when I say Business Requirements I mean VERY high level vision statements from a management level. They are almost irrelevant to the project in all but water cooler talk. The actual used requirements are User Stories.

Improve this question
2
  • 1
    I am not sure if i understand this all correctly, but I am under the impression in your environment there are a lot of people doing requirements analysis on too many different levels of abstraction. Sure your team works efficiently if there is room for so much philosophical discussion?
    – Doc Brown
    Feb 5, 2015 at 14:12
  • @DocBrown You are right about too many levels of requirement analysis but believe me when I say this is borne of necessity. Being polite as possible, I can only say that the Non-Technical BA's are quite poor at actually writing good requirements and often need a lot of hand holding. The abstraction comes from trying to fill in the gaps that they leave behind.
    – maple_shaft ♦
    Feb 5, 2015 at 15:12

1 Answer 1

Reset to default
2

Others still argue with the Non-Technical BA's claiming their requirements aren't specific enough and the Scrum master's answer is encouraging us to split things into total obfuscated oblivion with the hope that things become more estimable.

They are probably correct, although not about the obfuscation.

Requirements should be specific enough so that you can write a test for the requirement and have the customer agree that, if the test passes, the requirement is fulfilled and you can declare success.

If you still need more specificity to allow better estimates and provide better detail for the programmers to follow, then write a Software Design Specification. This would include things like Class Diagrams and Method Descriptions (inputs, outputs, purpose, etc.) The customer would not get involved in this... these are instructions just for the developers. The instructions do map directly to testable requirements, however.

Improve this answer
6
  • We have been espoused by Scrum zealots that have a holy crusade against a formal SDS document. Also an interesting caveat is that the business stakeholders wish to see and personally approve each user story and functional story. To give them a clear picture we must define all aspects of a complete testable functional requirement in user story form on the backlog. I suppose our problems is that the business demands the aspects of scrums while not abdicating the need to personally approve functional details.
    – maple_shaft ♦
    Feb 5, 2015 at 15:10
  • 1
    I think that getting approval from the stakeholders for stories is fine. Stories are business artifacts, after all. It doesn't have to be a formal SDS, and it doesn't even have to be done all at once, but the format should be standardized, and there should be enough detail so that the feature can be properly estimated and given to a developer to construct.
    – Robert Harvey
    Feb 5, 2015 at 15:15
  • 1
    I guess what I'm saying is that you need better informational boundaries between what the customer needs to know to make sure the project stays on track, and what the developers need to know to properly construct the software. Your scrum zealots should be cautious of the idea that a software design will just naturally emerge from the user stories.
    – Robert Harvey
    Feb 5, 2015 at 15:28
  • One of my previous jobs was in an industry where rapid prototyping was essential, and we used Scrum. This meant that we typically didn't have the time or the information to make meaningful design decisions. Also, there was a pretty good chance that your work would simply get scrapped a few sprints down the road. So, in our case, we were relying on a kind of emergent design. Now, that sounds scary and doomed to fail, but that's not necessarily true. As long as you invest enough time in things like hardening sprints you can pull it off. (end of tangential rant)
    – MetaFight
    Feb 5, 2015 at 16:03
  • 1
    @MetaFight It's not intractable; I've worked in such environments before, though they were not the most pleasant of experiences. Interruptions and changes in direction were common. Without some discipline, technical debt can build up rapidly, and I can't say with any degree of confidence that the software design that emerged was cohesive.
    – Robert Harvey
    Feb 5, 2015 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.