This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: what is it supposed to do?

 
William Stafford
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've read through my B&S requirements (called somewhat optimistically 'Application Submission', I hope I make it to that point) and I am not sure what it is being asking for.

In the background section the searching part of the task is described. "The new application ... must allow the customer service rep to generate a list of constractors [sic] that match a customer's criteria."

The User Interface section elaborates a bit by repeating the search requirement and adding that "It must allow the user to book a selected record..."

The last sentence of the description of the DB owner field says "If this field is all blanks, the record is available for sale".

Here come the questions.
1. Is booking the same as a "sale"?
2. Since record lock management is a major part of the application is there an implied requirement for un-booking?
3. If there is no un-booking what happens after all contractors are booked? It seems like the application would be pretty much useless at this point.
4. Just out of curiosity did Sun purposely create a really poor specification document or did they just create a really poor specification document?

I've been reading this board for a couple of weeks and I thought I had inferred all of the B&S requirements. Actually reading the requirements was somewhat of a shock.

Thanks in advance for any advice,
-=bill
 
Jason Moors
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi William,

1. Is booking the same as a "sale"?

I would simplfy this by saying you can only book contractors that are available for sale, i.e. where the owner field is blank.
2. Since record lock management is a major part of the application is there an implied requirement for un-booking?

There isn't a requirement to provide an un-booking mechanism for the GUI, although you could argue that the ability exists in the DBMain interface, as you could update the owner field to be blank. I wouldn't worry about providing un-booking, but you could mention in your design decisions document.
3. If there is no un-booking what happens after all contractors are booked? It seems like the application would be pretty much useless at this point.

Remember that you are implementing a DBMain interface, I think you can assume that other programs/tools will use the interface to add/remove records. For the assignment I wrote a few utilities to help be test 48 hour rule etc.
4. Just out of curiosity did Sun purposely create a really poor specification document or did they just create a really poor specification document?

Sun have made the requirements vague, so that you have to think about the implications and possible solutions.

Regards
Jason
 
Jeremy Botha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sun have made the requirements vague, so that you have to think about the implications and possible solutions.


This is, I believe, the crux of the matter. SCJP is easy. It's also easy to follow a cooking recipe for program assembly, viz: 'Lock this method', 'Use a Map as a cache', 'Use this table model for your GUI'.

What I suspect Sun are REALLY doing with SCJD is testing how capable you are of a) reasoning and critical thinking, b) programing ability and c) ability to curb your homicidal inclinations when dealing with an asinine program specification

jokes aside, the exam is not about programing, but rather about your ability to visualise the rather vague needs of a difficult client and present them with a working tech mock-up.

That's my interpretation of my experience with it, anyway.
J
 
William Stafford
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jeremy and Jason for the two thoughtful replies. I think my problem with the requirements is based on my experience in a very well run software development organization.

If someone in my group scheduled a review of those requirements I would have questioned their sanity. The lack of technical detail is not the problem, after all it is a requirements document not a design document. The big problem is that a design document should be unequivocal. Ambiguous requirements pave the way to failure or at least big problems down the line.

-=bill
 
Jeremy Botha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agreed 100%. I'm in the rather more (un?)fortunate position that in two of the three companies I've worked for since graduating, the Bodget and Scarper 'technical specification' would have been a well-written, thoughtful and insightful specification by comparison to what was frequently presented to me

Hence my comment about the 'assinine programing specification'

J
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic