Jump to content
Sign in to follow this  
ShaunR

Requirements Compiler

Recommended Posts

The problem is the people customers.  You must know that a requirements document, or rather a text document from a customer that very loosely describes what they want the software to do, is going to vary in format, wording, and technical level from customer to customer.

 

I've seen plenty of documents that were supposed to describe the software a customer wanted, but was more of a stream of consciousness, describing what they wanted, including but not limited to things like "the operator won't get bored using the software".  Good luck getting them to use a word like Boolean, or Enum.  This is hardly pseudo code, and requires some amount of magic and hand waving when it comes to bidding on project with this type of specifications.

 

For me the real meat of what needs to happen is a sit down conversation with the end user, asking what they want it to do.  Flush out what they really need, and what they want.  Understand priorities, and try to think of all the pit falls, technical limitations, and dead locks where they ask for something in one place and contradict it elsewhere.

 

I'm not saying it can't be improved, but I'm trying to say in my world why so much effort is put in translating this document to an output like software.

 

That being said I agree that you can fail CLD/CLA simply based on not understanding what it wants.  I remember hearing someone take the CLD coffee maker exam having never drank coffee, or knowing what it was.  If it were me in real life I'd sat down with the customer and discuss what they really want and how they want it to work.

 

By that I mean making sure hints and descriptions are filled in etc - you know, the stuff we don't actually do in real life. 

I do.

  • Like 1

Share this post


Link to post
Share on other sites

The problem is the people customers.  You must know that a requirements document, or rather a text document from a customer that very loosely describes what they want the software to do, is going to vary in format, wording, and technical level from customer to customer.

 

I've seen plenty of documents that were supposed to describe the software a customer wanted, but was more of a stream of consciousness, describing what they wanted, including but not limited to things like "the operator won't get bored using the software".  Good luck getting them to use a word like Boolean, or Enum.  This is hardly pseudo code, and requires some amount of magic and hand waving when it comes to bidding on project with this type of specifications.

 

For me the real meat of what needs to happen is a sit down conversation with the end user, asking what they want it to do.  Flush out what they really need, and what they want.  Understand priorities, and try to think of all the pit falls, technical limitations, and dead locks where they ask for something in one place and contradict it elsewhere.

 

I'm not saying it can't be improved, but I'm trying to say in my world why so much effort is put in translating this document to an output like software.

 

That being said I agree that you can fail CLD/CLA simply based on not understanding what it wants.  I remember hearing someone take the CLD coffee maker exam having never drank coffee, or knowing what it was.  If it were me in real life I'd sat down with the customer and discuss what they really want and how they want it to work.

 

I do.

 

You are in the wrong stage of the process.

 

If you are at the bidding stage, then you will be creating a proposal. That proposal becomes the specification after some back and forth and sit-down meetings. The supplier always wins the terms and conditions war as well as the final specification document. You obviously haven't gotten to the trick of making them adopt your specification by marking and amending your proposal.

 

Anyway. This is all somewhat relevant but a distraction.. We are talking, at this stage, of taking a precise, well defined document and doing what they do in the exams. If we produce a method of translating all NI CLA specifications into exam results (which I have sort of done already,  so know it is possible) We can discuss natural language heuristics later for general use cases.

 

Don't throw the baby out with the bathwater. :)

Edited by ShaunR

Share this post


Link to post
Share on other sites

Don't throw the baby out with the bathwater. :)

Either you misunderstood what I said, or you misunderstand what that expression means.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.