| Author | Message | ||
     Maxim Rusakov |
Hello, There is 1 ILF that includes STATE as an atribute with possible values: DRAFT, PUBLISHED, ARCHIVED. There should be 3 views: Drafts, Published, Archive. Views are identical except each of them shows only a subset of data. As so, we have 3 candidates for EQ: List drafts, List published, List archived entities. FTRs and DETs are identical for all these EQs. The only MINOR (from implementation point of view) difference is slightly different selection criterias. Should I count them as 1 EP or 3? P.S. Though there are several kinds of users in this application, all entites are visible to all users regardless their state. Otherwise I would assume that there should be 3 EP. | ||
| Steve Neuendorf |
Hello Maxim, There would be 1 EQ. For all three of the uniqueness tests, the three transactions are "identical". So even if there were a separate user requirement for each view, the 2nd and third views examined would not be unique and not counted separately. I would take this as an example of why 4.3 is worded as it is for uniqueness. Hope this helps, Steve | ||
| Maxim Rusakov |
Hello Steve, would you count as 3 EQ if these 3 lists were used to restirct access for different kind of users? Say, editors have access to list of drafts and list of published entties. Analytics have access to lists of published and archived. In general, can possibly you provide an example when you would count two EP different even if they share FTR and DETs? | ||
| Steve Neuendorf |
Hello Maxim, Your 3 EQs are very specific, and here the indication is that the DET, FTR and PL are identical. In 4.3, if they are identical they are not unique and only one is counted. If they are similar (not identical) and there is only one requirement, then they are not unique and finally, if they are similar AND have separate requirements they can be considered unique. Your description seems to be the views are restricted by which records a user can see. It would be the same answer even if which DETs the user could see were restricted even if the different users could see the same records. Under 4.2, any DET diversity would render the two views unique. Under 4.3, we seem to have adopted "similar" and made a distinction for identical. I would take that to mean that if user 1 can see DET A and not DET B and user 2 could see DET B and not DET A, literally under 4.2 that would unique, but under 4.3 they would be not unique. (The similarities overwhelm the differences). The problem is there is no good definition of what is meant by a "different requirement". I cannot see how modifiers to a requirement to reflect user access constraints could be considered separate independent requirements, so I don't see how you could construe this example to be anything other than the 1 EQ. Here is an example I could defend under 4.3, but I would not fully agree with. Say for an existing system everything is on an internal network. It is desired to implement the same functionality to run on the web. If the same inquiry is implemented via a separate requirement and it is not identical to the network version, say there are some additional DETs, 4.3 seems to indicate it is not unique. That is about all I can think of though. Hope this helps, Steve | ||
| Maxim Rusakov Username: Maximrusakov Post Number: 11 Registered: 04-2010 |
Thank you, Steve for pointing me to this difference between 4.2 and 4.3 CPM. |
