Skip to main content

Screenplays and Requirements

Yesterday I was reding about movies screenplays and found some analogies with writing requirements.

The screenplay must be readable, because filmmakers need to understand
- what they are talking about,
- who will be there,
- how much it will costs
- etc.


It is usually roughly divided in three parts: the set-up, the development, the epilogue (eg. 30, 60, 30 pages)

Many things change before and during shootings: dialogues change, sometimes you shoot a scene at night instead of during the day, etc. so....
"If you don't like changes, then go write poetry". This one rings a bell, doesn't it ?

Also, it will be read by the actors, who will interpret it and change it in some ways.

Labels:

Comments

Post a Comment

Popular posts from this blog

Vague requirements

An old school tip on vague requirements. A lot of words and sentences that we write in our requirements documents are often too vague . And these kind of unclear requirements have a big chance to cause problems at the end of your work. Blurred Something like: the system must be scalable , the system must be user friendly , the system must be quick . A good way to at least improve these three requirements could be something like this: 1. The system must be scalable up to 1.000 concurrent users without upgrading our servers, 2. The system must be usable by an average 50 years old accountant that only knows Word and some Excel, 3. The system must have any functinality ready on the screen  in 1" when all concurrent users are using the system. So, by just exploring a bit more with the stakeholders, you can reduce ambiguity a lot. It's not too difficult and you can have a huge improvement in the end product or service.
Post a Comment
More »

"Volere" Requirements process

I found in my library the "Mastering the Requirements Process" book , that some might know as the " Volere " book. After many years I still find it very useful. I don't think the good Robertsons invented anything really new, but I do believe that this book covers 90% of the "how to" solve requirements problems in software development.  And 90% is a lot ! The parts I appreciated more, this last time are: Chapter 12. Prototyping the Requirements  Working together to the prototype, can really take out the users' implicit knowledge, correct lapses and help in many other ways. Chapter 11. The Quality Gateway You could try put an analyst that doesn't work on the same project, to read the project's requirements and have him refuse: all incomplete or inconsistent entries, frills, etc. I think it can be a very powerful practice.
Post a Comment
More »

1. What is a Requirement ?

The word Requirement comes from the latin word Requisitum , that comes from requirĕre  «to demand, to require, to call for» and quaerĕre  «to ask, to strive for, to require». Never forget that asking a lot of questions is one of the key in understaning the real needs of your customers.
Post a Comment
More »