Login

Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Executable requirements
Previous Previous
 
Next Next
New Post 2/9/2010 9:17 PM
User is offline Manish
1 posts
No Ranking


Executable requirements 

 

“Ambiguity” in requirements means a requirement can have different interpretations. This leads to incorrect developed software which in turn leads to substantial amount of rework as most of them are uncovered during testing phase. The paradigm of executable requirements is an attempt to remove such ambiguities.
A requirement is called executable if it can be verified. In agile model driven development, acceptance tests, defined in the form of unit tests, constructs the executable requirements. Traditionally, acceptance tests are considered as testing artifacts. But actually, they are the core requirements artifacts as they describe the criteria by which the stakeholders will determine if the system meets their needs. Moreover, they are the unit tests written in functional code. Hence, acceptance tests are executable requirements. Business rules, features, non-functional requirements or GUI requirements can be captured in the form of executable requirements (acceptance tests). Few advantages of executable requirements are listed below:
  1. Executable requirements are specific.  General/unclear description will not serve the purpose as defining test cases require specific data and values.
  2. The developer easily understands the workflow the user expects. This can greatly enhance the usability of the application by taking the guesswork out of UI and workflow design. This, in turn, helps design of the data transformation and flow. By understanding the sequence in which the user wants to interact with the system, the developer can assure that the software not only works but is usable as well.
  3. This approach merges requirements, use cases and test cases. This results in removing discreet documents or systems and maintains traceability.
 
Executable requirements emphasizes on binary outcome of whether the tests are satisfied or not. This eliminates the scope of discussions with the stakeholders whether the requirement is satisfied or not. Run the automated acceptance tests and verify if the software meets the requirements or not.

Thanks !
Manish Kumar,Requirements Engineering Researcher,
[email protected]
http://researchmanish.blog.co.in/

 

 
 
 Page 1 of 1
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Executable requirements

Community Blog - Latest Posts

Jayaram.K
Jayaram.K

DOR & DOD: The BA’s Compass in Agile Delivery

As Business Analysts in Agile teams, we often hear about Definition of Ready (DOR) and Definition of Done (DOD). But beyond the buzzwords, these two concepts are powerful tools to drive clarity, consistency, and quality in our work. Definition of Ready ensures a user story is truly ready for development. It answers: Is this story clear, feasible...
Jayaram.K
Jayaram.K

The Business Analyst's Superpower: Bridging the Gap Between Business and IT

In today's fast-paced digital world, successful projects aren't just built on great code—they're built on clarity. And that clarity often comes from one key player: the Business Analyst. At the heart of every great product or system is a need—a business goal, a customer pain point, or a regulatory requirement. But busines...
Bekka Ball
Bekka Ball

Recipe Redesign: There Is No Box, Only Possibilities

I have always loved cooking. I learned from my Grandma June and her kitchen was her sanctuary, a small, warm sunlit space filled with jars of spices, stacks of cookbooks, and the comforting smell of something always on the stove or baking in the oven. Grandma June was as great a cook as she was a teacher to me. She never followed a recipe “to...

 



Upcoming Live Webinars




 

brought to you by Modern Analyst Media LLC enabling practitioners & organizations to achieve their goals using:

Copyright 2006-2025 by Modern Analyst Media LLC