Specifying the Functional Specification
Before setting out to design the MoreThan Talk platform. We needed to establish the precise specification in order to ensure that we do not miss out any key feature or attribute of the platform. Laura Brandenburg describes purpose of the ‘Functional Specification’ as being “to capture what the software needs to do to support a (business) user”.
We were going to do this in part through analysing the interviews – however since the ERGO process was not completed in time we were unable to complete these. We therefore had to create our own personas (see earlier blog) in order to understand how MoreThan Talk could be used and how it would relate to the experiences, expectations and needs of various potential users. We also discussed this as a group in order to try and pin down what we felt the MoreThan Talk social network should be seeking to achieve and more importantly how its technical construction would need to support the aims.
The table below was created in order to define the functional specification. In is a collection of all the possible features and attributes that MoreThan Talk could include. This is akin to a child’s Christmas wish-list, so we needed to apply some judgement over which features are essential and which are less so. One method that is used in this area is the MoSCoW method which was devised by Dai Clegg who was working on a rapid prototyping system and the aim is to draw designers and engineers to the most essential element of a design. In practise there is often a timeline element to the process which is not included here.
Pavel Kukhnavets writing on his blog acknowledges the advantages of the MoSCoW model as it can really help to rank and classify items in order to develop a successful and effective product. He sees the key benefits to include:
- It is based on expert opinion of the team.
- It is relatively quick and easy to complete.
That said, he also identified some potential drawbacks of the technique:
- MoSCoW rules can be subjective and therefore the prioritization can become largely inaccurate.
- The technique requires the team to have good familiarity with the product features. When there are different levels of expertise or familiarity it can make the ranking process uneven or draw unhelpful conclusions.
Incidentally the term MoSCoW is an acronym which comes from the first letter of each of four prioritization categories Must have, Should have, Could have, and Won’t have). Items receving a MUST absolutely have to end up in the final design. Items with WONT should not see the light of day. Other elements, the SHOULDS and the COULDs will be designed in as and when resources are available.
We are using a variety of categories for this
| Item | Description | MoSCoW |
| Signing-up and Logging on | ||
| 1 | Login screen seeks username and password | MUST |
| 2 | All entries to the site via and challenge for username and password | MUST |
| 3 | Inter-connectability – via dual logons with Google/Facebook and other platforms | SHOULD |
| 4 | Error message delivered for failed logon attempt | |
| 5 | Three failed login in attempts locks the account for 1 hour | WONT |
| 6 | User to choose their own username (assuming unique to the system) | MUST |
| 7 | Login screen to be available in different languages | SHOULD |
| Profile Page | ||
| 8 | Every user to have their own Profile Page | MUST |
| 9 | Users to be able to personalise their page | MUST |
| 10 | Users to be able to upload image of themselves | MUST |
| 11 | Users have a ‘news’ capability | SHOULD |
| 12 | Users have a ‘message’ capability | MUST |
| 13 | Users should be able to display a nationality flag | SHOULD |
| 14 | The profile page should be capable of being automatically translated into different languages | SHOULD |
| 15 | Profile Page should link to a map to indicate the location (city/region – fuzzy location) of the user | SHOULD |
| 16 | The Profile Page should indicate the groups that the user is a member of | SHOULD |
| 17 | Users able to create their own layout | WONT |
| 18 | Users should be able to upload photo albums | SHOULD |
| 19 | Profile Page could link to ‘information file’ about the user’s city/region/country | COULD |
| Sharing Personal Information | ||
| 20 | The user should be able to control which personal data is shared as public and with ‘friends’ | MUST |
| 21 | Personal | |
| Functionality | ||
| 22 | The site should have groups for people to join – City/country/interest | SHOULD |
| 23 | Users should be able to create their own groups | SHOULD |
| 24 | Users should be able to contribute to location based information – regardless of the groups they are members of | COULD |
| Protecting Personal Information | ||
| 25 | A user should be able to select the information that they make public | MUST |
| 26 | A user should be encouraged to change their password each month | WONT |
| 27 | A user’s e-mail address should never be published on the site | COULD |
| 28 | Personal data (username and passwords) to be kept encrypted on the main server | MUST |
| Searching for users | ||
| 29 | Provide a searchable database of user – so that users can be identified by their expertise | MUST |
| 30 | The writing of the query must be technically hidden from the user – aim for simplicity | MUST |
| 31 | Matches should be possible due to Language spoken | MUST |
| 32 | Matches should be possible due to Country someone lives in | MUST |
| 33 | Matches should be possible due to identify areas of interest through drop-down list or tick buttons | MUST |
| 34 | The return for searches must deliver all the possible matched on one screen – as a list | MUST |
| 35 | Matches should have links to their profile – for ease of access | SHOULD |
| 36 | Matches should be connactable via a ‘message’ button | MUST |
| 37 | When a message is received a – prompt message – should be sent to the users e-mail address to advice them or the new message | COULD |
| 38 | Users should be able to leave ‘recorded’ messages for matched | COULD |
| 39 | ||
| Maintaining personal data security | ||
| 40 | To be challenged for user name and password each time of entry onto the site | MUST |
| 41 | Users have to set a ‘secure’ password – we specify length, characters etc. | SHOULD |
| Monetization | ||
| 42 | Advertising blocks to be placed by third-party | MUST |
| 43 | System to include analytics to allow feedback to advertisers | MUST |
| 44 | AdWord systems to be allowed to link advertisements to the key words or locations of interest. | MUST |
| Administration | ||
| 45 | Secure login available to all site supervisors | MUST |
| 46 | The ability to assign moderation duties to third-parties | MUST |
| 47 | The ability to suspend accounts | MUST |
| 48 | The system should have capability to automatically publish warnings regarding abuse/inappropriate images/ and so forth. | MUST |
References
1. Laura Brandenburg (Unknown) What Requirements Documents Does A Business Analyst Create? Available at the Gap http://www.bridging-the-gap.com/requirements-documentation/
2. Pavel Kukhnavets (2016) ‘MoSCow Method: the Most Successful Prioritization Technique For Any Project’ – Gattpro Blog – https://blog.ganttpro.com/en/prioritization-techniques-and-methods-for-projects-with-advantages-of-moscow-model/
No comments yet.