I'm doing a research on formulating a requirements analysis model as a stage of requirements engineering for mobile-application development by considering the limitations and the needs of it ( agility and etc.. .), what I'm trying to figure out is that which parts of this process (requirements analysis for mobile development) are the most challenging ones ( so i can focus more on) , and if there is any stage that u think I need to include or exclude (exp. some may think a quality plan may or may not be necessary and etc.)

to make it more clear below is the list of few of the areas in which I can focus on ( by the way your suggestions can be anything out of the below list.)

-Requirements specification -Prototyping -Requirements Prioritization -Focusing on quality functions


Horizontal traceability of functional requirements.

Vertical traceability, from parent requirement to child requirement, has long been considered an important part of requirements analysis. Horizontal traceability is a new concept that has only recently become feasible.

Functional requirements take input data, do some kind of processing, and produce an output data item. If there are no missing requirements, all of the system outputs can be traced back through a series of requirements, to the system inputs.

The "trace" is done by noting that every input data item must be the output of some other requirement. Thus the requirements are horizontally connected, input to output. Missing connections mean missing requirements.

Verifying the horizontal traceability of more than a handful of requirements "by hand" is simply infeasible. Using a spreadsheet macro to do the analysis makes it possible to easily find most of the missing requirements.

It is very new and not well known. I wrote an Excel macro to partialy automate the process. It is available for free at http://www.barbarabea.com/?page_id=11

There is also a tutorial and user guide.

I have used it on a few projects. One of the projects had a mature set of requirements, i.e. a product based on those requirements had been completed and shipped. When those reqs were put in the spreadsheet we found that there were a lot of reqs missing. (~40%) Another project used it to write new functional requirements. For the new reqs, the graphical output was the most important part. Seeing how all the reqs tied together helped identify which reqs should be written next and which needed to be modified because they did not fit well with the rest.

I do have another idea. But it is more academic than practical. It is also written up at the Barbara Bea blog.

One of the characteristics of a good requirement, we are told, is that it is unambiguous. This is usually defined as having only one possible interpretaion. Any high level requirement that has child requirements is ambiguous. Otherwise it would not need child requirements.

But how do you go about deciding whether or not a requirement is ambiguous? I have created an objective test to determine if a functional requirement is ambiguous. If you start with a set of functional requirements that are horizontally connected, then each functional requirement is unambiguous if, and only if, the processing step is an algorithm.

Told you it was academic. But it is also the only objective test for ambiguity that I have ever seen.

  • I've red your answer few times and have been searching on it ever since, it seems like a really new area, since there are not many info about it on the NET, and that's amazing, two things to mention firstly do u know any good resource about this topic? and secondly any other amazing idea like this one? before i close the session for the question?
    – user363295
    Apr 15 '12 at 10:07
  • That's a great Idea, to be honest one the best I've ever heard, By the way I don't understand why you think its more of academical and can't be practical, ( well time can be a concern, since i believe it gone be a bit time consuming), but when it comes to large projects it can be a great idea, (well...if someone can come with a standard solution for it!!)
    – user363295
    Apr 16 '12 at 16:29
  • 40%!!!! wow, that's a lot, especially if it comes to large projects, That can cause a huge failure!.
    – user363295
    Apr 16 '12 at 16:41

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